نگهداری و رسیدگی
این فصل پوشش میدهد
- نگهداری سختافزار
- پایش سلامت پلتفرم شما و تکنیکهای پشتیبانگیری و بازیابی
- پایبند ماندن به بودجه
مدیریت سلامت و نگهداری مداوم سازمان یا پلتفرم چیزی است که اغلب بدیهی فرض میکنیم. اینهمه تلاش صرف طراحی، ساخت و استقرار میکنیم، اما گاهی فراموش میکنیم روشن نگه داشتن چراغها، پیشگیری از مشکلات احتمالی و ساختن محیطی که اگر چیزی از مسیر خارج شد، امکان بازیابی در آن وجود داشته باشد چه میطلبد.
در این فصل به چند حوزه سطحبالا میپردازیم که بسیاری از CTOها را غافلگیر کردهاند. اینها به احتمال زیاد موارد رویهای بدیهی هستند، اما گاهی حتی چیزهای بدیهی هم از قلم میافتند. برای مثال، بسیاری از ما باور داریم که از پلتفرمهایمان بهطور کامل پشتیبان میگیریم، اما آخرین بار چه زمانی واقعا تلاش کردید یک سیستم را بازیابی کنید؟ چقدر مطمئنید که نسخه پشتیبان همه چیزهایی را که لازم دارید پوشش داده است؟
همانطور که هنگام توسعه کد درباره تولید بدهی فنی صحبت کردیم، اگر مراقب کل سازمان یا
پلتفرم نباشید، بدهی فنی میتواند آنجا هم رخ دهد. سرویسدهی منظم به پلتفرم، بهطوری که غافلگیریای سر برنیاورد، نقشی است که اغلب
نادیده گرفته میشود.
۱۳.۱ نگهداری سختافزار
اگر در پلتفرم خود سرورهای فیزیکی یا تجهیزات شبکه دارید، باید برای آنها برنامه مدیریتی بسازید. سختافزار موجودی زنده است که به مراقبت و نگهداری پیوسته نیاز دارد، بهویژه قطعاتی که بخش متحرک دارند؛ فنهای خنککننده را هم در همین دسته میگذاریم. هر چیزی که قطعه متحرک داشته باشد، سرانجام از حرکت میایستد و پیامدهای ناگفتهای ایجاد میکند. هدف این است که پیش از خرابی به استقبال آن بروید، برایش برنامهریزی کنید، انتظارش را داشته باشید و در نهایت وقتی رخ میدهد نگران نشوید.
همانطور که پیشتر گفته شد، نگه داشتن یک موجودی قابل اعتماد و بهروز برای سلامت سختافزار شما حیاتی است. این موجودی شامل جزئیاتی مانند موارد زیر است:
- سازنده
- نوع/مدل
- تاریخ خرید/تاریخ نصب/تاریخ سرویس بعدی و جزئیات پشتیبانی
- گزارش نگهداری
- جزئیات مکان/ورود
یک صفحهگسترده ساده کافی است، اما نرمافزارهای تخصصی موجودی هم وجود دارند که در این کار کمک میکنند. سرویس سختافزار مانند سرویس خودرو است؛ بله، میتوانید تعویض روغن را عقب بیندازید و کمی پول ذخیره کنید، اما در نقطهای موتور میترکد و علاوه بر دردسر و توقف، پول بیشتری روی دستتان میگذارد. در دنیای سختافزار فناوری روغنی برای تعویض وجود ندارد، اما دیسکهای سخت، از جمله SSDها، و فنهایی دارید که باید جایگزین شوند. هر قطعه یک MTTF، یعنی میانگین زمان تا خرابی، دارد که در اصل عمر مورد انتظار آن است. قطعات ممکن است بیشتر دوام بیاورند، اما میتوانند زودتر هم بمیرند. مهم است که قطعات را زودتر تأمین کنید و اگر ممکن است جایگزینها را در انبار داشته باشید.
سختافزار وقتی دردسرساز میشود که به سنی برسد که تأمین قطعات دشوار یا تقریبا غیرممکن شود. غیرمعمول نیست که شرکتها به مزایدههای eBay پناه ببرند و دنبال دستگاههای دستدوم بگردند. برنامهریزی کنید که خیلی پیش از آن مرحله آماده باشید، چون اگر
حواستان نباشد، میتواند ناگهان غافلگیرتان کند.
قراردادهای پشتیبانی طی سالها بدنام شدهاند و اغلب گزینهای گرانقیمت دیده میشوند که در نهایت با گذشت زمان بیش از خود مجوز برای آن پول میپردازید. بعضی از فروشندگان شناختهشده پایگاه داده به همین موضوع معروف بودند.
۱۳.۲ قراردادهای پشتیبانی
قراردادهای پشتیبانی را باید مانند بیمهنامه دید؛ وقتی اوضاع خراب میشود، آنجا هستند تا کمک کنند دوباره سرپا شوید و کار را راه بیندازید. با این حال، مانند بیمهنامهها، همه قراردادهای پشتیبانی یکسان نیستند و ممکن است آن نوع کمک یا پشتیبانیای را که واقعا لازم دارید فراهم نکنند. بنابراین پیش از امضای قراردادی طولانی، مطمئن شوید سطح پشتیبانی لازم برای سرپا نگه داشتن سازمانتان را میدهد. انواع رایج پشتیبانی عبارتاند از:
- ارتقاهای کوچک و سریع یا بهروزرسانیهای امنیتی
- زمان پاسخ تضمینشده به یک پرسش؛ این به معنای حل مسئله نیست، فقط یک
تأیید دریافت پرسش شماست
- پشتیبانگیری زمانبندیشده، اگر آنلاین باشد
- بازیابی بحران/جابهجایی هنگام خرابی
- جایگزینی قطعات/مؤلفهها هنگام خرابی
بسته به تخصص و توان داخلی سازمانتان، شاید به همان سطح پشتیبانیای که دیگران از آن سود میبرند نیاز نداشته باشید. تعیین اینکه آیا به پشتیبانی نیاز دارید و اگر دارید در چه سطحی، از تحلیل ریسک هر یک از مؤلفههایتان به دست میآید؛ با پرسشهایی مانند موارد زیر:
- اگر این مؤلفه خراب شود، چه اثری بر تحویل به کاربر نهایی دارد؟
- چه میزان دانش یا آموزش داخلی برای حل مسئله وجود دارد؟ چند وقت یکبار با مشکل روبهرو شدهاید؟
- آیا این مؤلفه نقطه شکست یگانه است؟
گاهی قرارداد پشتیبانی چیزی بیش از وزندهی اولویت نیست. برای مثال، مشکلی را در خط اینترنت ورودی ساختمان خود در نظر بگیرید. البته ارائهدهنده در نقطهای آن را حل میکند، اما احتمال دارد مشتریانی را که قرارداد پشتیبانی دارند نسبت به مشتریانی که ندارند در اولویت بگذارد.
همین اتفاق در نرمافزار هم رخ میدهد. ارائهدهندگان ابر سطح پایهای از پشتیبانی را رایگان ارائه میکنند، اما پاسخ دادن یا بازیابی سیستمها برای آنها ممکن است چند روز طول بکشد، در حالی که برای کسانی که قرارداد پشتیبانی دارند چند ساعت است. قرارداد پشتیبانی را مانند طناب نجات ببینید؛ همان شمارهای که وقتی همه راههای دیگر تمام شدهاند با آن تماس میگیرید. برای سیستمهای قدیمیتری که هنوز مدرنسازی یا بهروزرسانی نشدهاند، حتما باید قرارداد پشتیبانی داشته باشید تا این فاصله را تا زمانی که برای رسیدگی به مؤلفه زیربنایی برنامه دارید پوشش دهد.
کتابخانهها یا نرمافزارهای متنبازی که به آنها تکیه دارید نیز نامزد پشتیبانی هستند. بسیاری از پروژههای متنباز بزرگتر، مانند Mongo، Postgres، MySQL و Elasticsearch، نسخه «تجاری» قابل خرید دارند که معمولا فقط یک قرارداد پشتیبانی است و همان نرمافزار متنباز زیر آن قرار دارد. برخی نسخهای تجاری ارائه میکنند که با مبلغی کم، چند بازبینی عقبتر است و گاهی ویژگیهای اضافه مخصوص سازمان دارد، تا مجبور نباشید مشکلات «دندان درآوردن» انتشار را که گاهی با نرمافزارهای سریعانتشار همراه است تحمل کنید. آنها همچنین مطمئن میشوند بدون اتکا به اینکه کسی از تیم شما منابع آنلاین را بررسی کند، بهموقع از بهروزرسانیهای امنیتی مهم باخبر میشوید.
قراردادهای پشتیبانی سختافزار میتوانند از نظر هزینه و سرویس بهشدت متفاوت باشند. قراردادهای سطح بالا سختافزار شما را از راه دور پایش میکنند و مهندسی
۱۳.۲.۱
پیش از آنکه اصلا بفهمید قطعهای خراب شده، بهطور خودکار برای جایگزینی اعزام میشود. این نوع قرارداد برای سرورهای بزرگ SAN، یعنی شبکه ذخیرهسازی، رایج است، چون دیسکهای سخت به پایان عمر خود میرسند. قراردادهای سطح پایینتر مشکل را از طریق تلفن یا ایمیل تعیین میکنند و جایگزینی میفرستند تا تیم شما خودش نصب کند. به قول قدیمیها، هرچه پول بدهی همانقدر آش میخوری. همه به سرویس کامل سطح بالا نیاز ندارند، اما تصمیم با شماست.
ارائه پشتیبانی
حالا که درباره پشتیبانی صحبت میکنیم، ارزش دارد سمت دیگر میز را هم در نظر بگیریم: برای سیستمهایی که به مشتریانتان ارائه میکنید، وقتی دچار مشکل میشوند چه سطح پشتیبانیای عرضه میکنید؟ در سازمانهای بزرگتر رایج است که گروه پشتیبانی خط مقدم زیر نظر COO یا CIO باشد. این افراد مستقیما با مشتری نهایی تعامل میکنند و میکوشند مشکلات را تشخیص دهند و حل کنند. اگر به کمک نیاز داشته باشند، موضوع به گروه مهندسی ارجاع میشود. بنابراین هرچند شما مستقیما در پشتیبانی کاربر نهایی دخیل نیستید، همچنان باید فرایندی داشته باشید که پاسخ بهموقع به تیم پشتیبانی شما را تعریف کند. این اغلب SLA، یعنی توافقنامه سطح خدمت، نامیده میشود و سطح خدمتی را که کاربر نهایی میتواند انتظار داشته باشد دریافت کند مشخص میکند (فصل ۱۰ را ببینید). این نوع توافق معمولا مواردی مانند زیر را شامل میشود:
- زمان در دسترس بودن در یک بازه زمانی؛ برای مثال، ۹۹.۹۹۹٪ در یک سال یعنی بیش از ۸.۷ ساعت توقف نخواهید داشت.
- زمان تأیید دریافت یک درخواست، با جزئیات زمان پاسخ در ساعات کاری و خارج از ساعات کاری.
- هر نوع پایش از راه دوری که دارید.
- وصلههای نرمافزاری، شامل اصلاح باگ و بهروزرسانیهای امنیتی.
- حداکثر زمان صرفشده برای یک مسئله منفرد یا در کل.
- صورتحساب برای هر مسئلهای که «تقصیر شما نیست».
نباید این فهرست را در خلأ بسازید. این کار با همکاری تیم فروش، مدیر محصول، CEO و CFO انجام میشود. نتیجه چیزی است که مشتری میخواهد، چیزی که تیم فروش میتواند بفروشد و در نهایت چیزی که شما میتوانید تحویل دهید. بنابراین اگر تصمیم گرفته شود که پشتیبانی خارج از ساعات کاری ارائه شود، باید برای آن نیرو تأمین کنید؛ تیمهای دورکار در منطقههای زمانی مختلف، چرخش کارکنان با پیجر یا کارکنان شبانهروزی، و هزینهاش را در بودجه بگذارید.
هرگز در موقعیتی نباشید که پشتیبانی ۲۴/۷ ارائه کنید بدون اینکه برنامه واقعی برای تحویل آن داشته باشید. درست زمانی که شام Thanksgiving یا کریسمس آماده شده، نیاز به انجام آن پیش خواهد آمد. اتکا به سالها حسننیت تیم، یا امید داشتن به اینکه هرگز رخ ندهد، راهبرد پشتیبانی نیست. همان سطح پشتیبانیای را ارائه کنید که خودتان از یک فروشنده مطالبه میکنید.
هیچ چیز غیرحرفهایتر و راستش شرمآورتر از این نیست که مشتری به شما گزارش دهد چیزی از کار افتاده یا در دسترس نیست؛ با این حال، در نقطهای از مسیر حرفهای، همه ما در سمت اشتباه این ماجرا بودهایم. ساختن فرهنگ پایش کمی فکر میخواهد، اما وقتی کامل شود به شما و تیم اجرایی سطحی از آرامش میدهد.
۱۳.۳ پایش
۱۳.۳.۱ نگاه از بیرون به داخل
اگر کاربر یا مشتری اصلی شما بیرونی است، باید طوری پایش کنید که انگار جای او هستید. هرچقدر هم بدیهی به نظر برسد، یعنی هر نرمافزار پایشی باید بیرون از شبکه فعلی شما قرار بگیرد. برای مثال، اگر روی AWS میزبانی میشوید، راهکاری را در نظر بگیرید که از Azure یا Google استفاده میکند، یا دستکم از یک حساب AWS کاملا جدا در منطقه جغرافیایی متفاوت.
پایش بیرونی یعنی دسترسی دورهای به زیرساخت شما به شکلی که تعامل یک مشتری واقعی را شبیهسازی کند. این کار میتواند از تشخیص ساده در دسترس بودن یک سرویس مشخص شروع شود و تا اندازهگیری تأخیر و زمان پاسخ ادامه یابد. هنگام طراحی چنین پایشگری از راه دور، مطمئن شوید طوری طراحی شده که اگر چیزی هشدار داد، سرنخهایی به تیم شما بدهد که مشکل واقعا کجاست.
برای مثال، میتوانید فقط دسترسپذیری صفحه وبی را که برای ورود استفاده میشود پایش کنید. هرچند این قدم اول خوبی است، اما تأیید نمیکند که API احراز هویت مشتریان در دسترس است. اگر همین مسیر را ادامه دهید و حساب آزمایشیای داشته باشید که بتوانید با آن وارد شوید، احراز هویت تأیید میشود؛ اما آیا سرویسهای اصلی هم لمس شدهاند؟ آیا میتوانید API دیگری را بزنید که یک پرسوجوی کمهزینه روی پایگاه داده اصلی اجرا کند؟ با افزودن چند گام اضافه، ببینید چه چیزهای بیشتری اعتبارسنجی میشود: شبکه، API و پایگاه داده. این کار را هر ۵ تا ۳۰ دقیقه انجام دهید، بسته به اینکه چه چیزی منطقی است، و خیلی سریع میفهمید چه زمانی اوضاع رو به خرابی میرود.
وقتی چیزی شروع به هشدار دادن میکند، آن هشدارها باید کجا بروند؟ پاسخ منطقی تولید ایمیل است، اما کدام ایمیل؟ اگر ایمیل را روی همان شبکهای مدیریت میکنید که پایش میشود، خطر این وجود دارد که ایمیل نرسد، چون همان مشکلی که جلوی دسترسی مشتری را گرفته میتواند مانع عبور ایمیل هم بشود. این دلیل خوب دیگری برای برونسپاری نیازهای ایمیل به Google یا Microsoft است؛ فارغ از اینکه در شبکه خودتان چه میگذرد، ایمیل همیشه در دسترس خواهد بود. اگر سرور ایمیل خودتان را میزبانی و مدیریت میکنید، به استفاده از یک نشانی ایمیل رایگان مانند Gmail، Yahoo و غیره فکر کنید که ایمیل را به افراد مربوطه فوروارد کند؛ نشانیهایی را انتخاب کنید که روی دامنه اصلی شما نیستند.
اگر ایمیل را برونسپاری کردهاید، از همان فرایند استفاده کنید: یک نام مستعار «هشدار» بسازید که بعد به همه کسانی که باید آن را ببینند فوروارد شود. اداره یک فهرست ایمیل بسیار آسانتر از تلاش برای نگهداری ایمیلهای فردی است.
موضوع خوب دیگری که باید در نظر گرفت، یک صفحه وضعیت عمومی با شاخصهایی درباره زمان در دسترس بودن هر مؤلفه عمومی است. نمونههایی از این را از طرف Amazon و Azure دیدهاید. بسیاری از ابتکارهای متنباز ساخت چنین صفحهای را ساده کردهاند. باز هم مطمئن شوید صفحه وضعیت بیرون از شبکه اصلی سازمان است.
۱۳.۴ پشتیبانگیری و بازیابی
تقریبا همه ادعا میکنند نسخه پشتیبان دارند، دستکم از مؤلفههای حیاتی؛ اما همانطور که Ryan Burch، مدیر IT در New Harbor Capital، با تأسف میگوید: «شاید بدیهی به نظر برسد، اما راهبرد پشتیبانیای که هرگز بازیابی نشده، پشتیبان نیست؛ فقط راهبرد استفاده از ذخیرهسازی است، چیزی که به شما احساس امنیت بدهد، مانند تور ایمنیای که به هیچجا بسته نشده است.»
ساخت نسخه پشتیبان سخت است، و تا وقتی یک بازیابی کامل روی سیستمی دیگر انجام نداده باشید، هرگز نمیفهمید آیا واقعا از همه چیز پشتیبان گرفتهاید یا نه.
اولین پرسشی که باید
پاسخ دهید این است: از چه چیزی پشتیبان
میگیرید؟ فقط داده، پیکربندی
و داده، یا برنامه، پیکربندی و داده؟ پاسخ به این پرسش در وهله اول به هدف پشتیبانگیری بستگی دارد. چند دلیل برای ساخت راهبرد پشتیبانگیری عبارتاند از:
- تداوم خدمت در صورت خرابی و ثبت دورهای برای انطباق
- اهداف آزمایش/توسعه
اکثریت قریب به اتفاق نسخههای پشتیبان برای رخدادهای تداوم خدمت ساخته میشوند، و در این موارد زمان اهمیت دارد. هر دقیقه توقف هم از نظر مالی هزینه دارد و هم از نظر اعتبار/اعتماد برند شما. ساختن راهبرد و تمرین کردن آن، اگر بدترین اتفاق رخ دهد، نهتنها آرامش خاطر به شما میدهد، بلکه برنامه و انتظار زمانی مشخصی فراهم میکند برای اینکه چه زمانی یک سرویس دوباره عملیاتی خواهد شد.
بسته به چیدمانتان، توصیه میشود فایلهای پشتیبان را بهصورت رمزنگاریشده روی شبکه یا حساب ابری جدا نگه دارید. بیشتر اوقات، بهویژه در سازمانهای کوچکتر، رایج است که نسخههای پشتیبان روی همان ماشین قرار داشته باشند و حتی روی شبکه جدا نباشند. همیشه با این فرض کار کنید که پرسش «اگر» خرابی رخ دهد نیست، بلکه «چه زمانی» رخ میدهد.
پشتیبانگیری باید سرویسهای شخص ثالث را هم در بر بگیرد، نه فقط سرویسهایی را که مستقیم نگهداری میکنید. برای مثال، کد منبعی که روی GitHub یا Bitbucket قرار دارد باید بهطور منظم در مکانی امن و مدیریتشده پشتیبانگیری شود. حوزه دیگری که اغلب نادیده گرفته میشود Salesforce است، بهویژه اگر بیشتر مانند پایگاه دادهای در ابر از آن استفاده میکنید. اگر از Google Drive، Office 365، Dropbox یا هرجایی که داده دارید استفاده میکنید، از خود بپرسید اگر دیگر در دسترس نباشد یا از حساب بیرون قفل شوید، پیامدش چیست؟
قرار دادن یک راهبرد خوب در جای خود، همراه با استخراج یا کپی اولیه، تلاش میخواهد. اما پس از آن باید روی حالت خودکار باشد، با گزارشهایی که در محیط لاگ مرکزی شما ثبت میشوند تا برای زمانی که پشتیبانگیری شکست میخورد یا حتی اجرا نشده هشدار بسازید.
بازیابی خود را تمرین کنید. برنامهای بسازید که بهروشنی در دسترس باشد تا هر کسی با حقوق مدیریتی لازم بتواند بهآسانی بسازد و بازیابی کند. دستکم سالی یکبار، یا بیشتر، تمرین آتشنشانی داشته باشید تا تأیید شود از همه چیز همانطور که انتظار میرود پشتیبان گرفته میشود.
۱۳.۴.۱ تناوب/نگهداری
پرسشی که مرتب مطرح میشود این است که پشتیبانها هر چند وقت یکبار باید ساخته شوند و چه مدت باید نگهداری شوند. بیایید هر یک از این مسائل را بهترتیب نگاه کنیم.
بزرگترین عامل در اینکه هر چند وقت یکبار باید پشتیبان بگیرید، به این برمیگردد که داده شما چند وقت یکبار تغییر میکند. اگر فقط هفتهای یکبار تغییر میکند، پشتیبان روزانه تفاوت زیادی میان آرشیوها ایجاد نمیکند. پشتیبانگیری بیش از حد مکرر میتواند سربار زیادی ایجاد کند، هم در عملکرد و هم در مصرف دیسک. اگر به وضوح بالایی در بازیابی نیاز دارید، باید به ساختن آن از پایه در ذخیرهسازی فکر کنید؛ مثلا تکثیر داده چندمنطقهای تقریبا در زمان واقعی.
مدت نگهداری نسخههای پشتیبان زمانی تابعی از فضای ذخیرهسازی موجود بود. با ظهور ذخیرهسازی ابری پرداخت بهازای مصرف، آن حد عملی دیگر وجود ندارد. اکنون پرسش بیشتر به این سمت میرود که برای سناریوی بازیابی چه چیزی مفید است.
در روزگار قدیم توصیه این بود که سه نسخه پشتیبان آخر نگه داشته شوند تا هرگونه از دست رفتن یا خرابی یک نسخه پشتیبان پوشش داده شود. با ذخیرهسازی بزرگ و چکسامها و رمزنگاریهای پیشرفته، این دیگر مسئله سابق نیست. تا زمانی که دستکم یک آرشیو پشتیبان دارید، برای بیشتر رخدادها کافی است. با این حال، اگر فکر میکنید برای بازیابی جزئی باید به نسخه پشتیبان رجوع کنید، یعنی باید آرشیوها را بیش از حالت عادی نگه دارید.
فرض کنید کشف میکنید مجموعه مشخصی از داده بهطور تصادفی حذف شده، اما چند روز یا چند هفته طول کشیده تا متوجه شوید؛ موقعیتی که هنگام مدیریت داده مشتریان چندمستاجری غیرمعمول نیست. اینکه بتوانید به گذشته برگردید و استخراج جزئی برای نقطه زمانی مشخص انجام دهید، ممکن است بهتر از هیچ باشد. بنابراین نگه داشتن داده برای چند ماه قابل توجیه است.
نکته: این به معنای آن نیست که باید شش ماه داده روزانه نگه دارید. میتوانید آن را بهتدریج پیر کنید: مثلا پس از هفت روز، فقط یک آرشیو هفتگی نگه دارید؛ سپس پس از چهار هفته، فقط آرشیوهای ماهانه را نگه دارید. این تکنیک نسلبندی هزینههای ذخیرهسازی را پایین نگه میدارد.
۱۳.۴.۲ امنیت آرشیو
پیش از ترک این موضوع، یک هشدار درباره امنیت آرشیو حاصل: بسیار آسان است که از طریق امنیت ضعیف و دسترسی به آرشیو حاصل، داده حساس را افشا کنید. نمیخواهید همه تلاشهای امنیتی شما برای حفظ دسترسی چندلایه با در دسترس قرار دادن فایل فشرده یا پشتیبان برای هر کسی که کنترل DevOps دارد بیاثر شود.
فردی که مسئول اجرای پشتیبانگیری و اعتبارسنجی آن است، لازم نیست بتواند داده داخل آرشیو را ببیند. با کنترل دسترسی به کلیدهای رمزنگاری، میتوانید یکپارچگی و قابلیت مشاهده آرشیوهای پشتیبان را حفظ کنید.
با فایلهای پشتیبان خود همان سطح توجهی را داشته باشید که با محیط مربوط به آنها دارید. نگذارید نسخههای پشتیبان شما داده نشت دهند.
۱۳.۵ نظارت بر بودجه
همانطور که در فصلهای پیشین مرور کردیم، ساختن بودجه به شما و کسبوکار معیاری برای تحویل آنچه نیاز دارید میدهد. این فقط بخشی از نظارت بر بودجه است؛ بخش دوم چالش، پایبند ماندن به آن است. یعنی هزینهکرد و هزینهها را همانطور که رخ میدهند پیگیری کنید و با هیچ غافلگیریای بیخبر نمانید.
خبر خوب: اگر در ابر هستید، دسترسی به این اطلاعات از طریق هشدارهای روزانه، اگر آستانههای مشخصی رد شوند، بسیار آسان است. هزینههای ابری بهسادگی میتوانند مارپیچی بالا بروند، بهویژه اگر توسعهدهندگان سرویسهای جدید بسازند، شاید بزرگتر از نیازشان، و بعد فراموش کنند آنها را خاموش کنند.
عادت خوبی که باید بسازید این است که دستکم ماهی یکبار
بازبینی هزینههای ابری داشته باشید
تا منابع فعلی در حال اجرا را مرور کنید و تعیین کنید آیا لازماند یا نه. از تگهایی که ارائهدهندگان ابر برای ردیابی سرویسهای مختلف میدهند آزادانه استفاده کنید، شاید در سطح پروژه یا دپارتمان. بسیار آسان است که سرورها بالا بیایند، سپس نیاز واقعیشان فراموش شود و با گذشت زمان مقدس شوند. افراد از آسیبهای ناگفته در صورت خاموش کردنشان میترسند، پس نگه داشتنشان روشن، یعنی خرج کردن پول، آسانتر است. پیش از آنکه بفهمید، قبض ابر از کنترل خارج شده است.
دلیل دیگر بالا رفتن قبض ابر افزایش مصرف است. یک پروژه بومی ابری قوی و خوب معماریشده بر اساس سطح ترافیک بهطور خودکار بالا و پایین مقیاس میشود
. با رشد محصول، تیم فروش چند مشتری بزرگ جدید میآورد، پس مصرف افزایش مییابد و هزینه هم همینطور. این خوب و طبیعی است. با این حال، باید بتوانید دلیل افزایش قبض ابر را شناسایی کنید تا وقتی CFO میپرسد، بتوانید همراه او دلیلش را جشن بگیرید.
در هر صورت، بازبینی و پایش مداوم جلوی غافلگیریها را میگیرد، و اگر لازم باشد بودجه اولیه خود را تنظیم کنید، همین است دیگر؛ آن بودجه از ابتدا فقط یک برآورد بود، و با گذشت زمان آن را با آنچه واقعا رخ میدهد محکمتر میکنید.
اگر بیرون از ابر هستید، هزینههای شما در قالب مبلغهای بزرگ یکباره میآید، وقتی میخواهید سرور، حافظه یا فضای دیسک بیشتری اضافه کنید. همان قواعد ابر اینجا هم صدق میکند: مصرف فعلی سرویسها را بازبینی کنید و مطمئن شوید تا حد ممکن کارآمد استفاده میشوند. ذخیرهسازی حوزهای است که میتواند بیپایان باشد. اگر افزایشی میبینید، به واگذاری نیازهای ذخیرهسازی بلندمدت خود به ابر فکر کنید؛ برای چیزی که لازم دارید پول بدهید، بدون نگرانی از تمدید سختافزار.
مجوزهای نرمافزار و هزینههای پشتیبانی کمی آسانتر پیشبینی و بودجهبندی میشوند، اما میتوانند سال به سال افزایش یابند و واقعا هم افزایش مییابند. هزینه مجوز پایگاههای داده تجاری معمولا بالا است، بنابراین وقتی نیاز به رشد دارید، عقب بایستید و تعیین کنید آیا جایگزینهایی، ارزانتر یا رایگان، در دسترس هستند یا نه.
هرچند توصیه میشود هنگام گرفتن یک برنامه نرمافزاری جدید پشتیبانی بگیرید، وقتی زمان تمدید میرسد بپرسید آیا آن پول خوب خرج میشود و آیا واقعا به نرمافزار نیاز دارید یا نه. این یکی از دلایلی است که بسیاری از شرکتهای نرمافزاری از قراردادهای پشتیبانی به مدلی مبتنی بر اشتراک حرکت کردهاند و شما را مجبور میکنند تا زمانی که به استفاده از محصول ادامه میدهید پول بدهید. باز هم، بهعنوان CTO، شما مسئول هزینههای دپارتمان خود هستید و باید برای بهترین ارزش در بودجه تخصیصیافته خود بجنگید.
جمعبندی
- از سختافزارهای تحت کنترل خود موجودی نگه دارید تا نگهداری پیشگیرانه را بهتر زمانبندی کنید.
- تعیین عمر قطعات، نیازهای خرید شما را از پیش هدایت میکند.
- قراردادهای پشتیبانی مانند بیمهنامه هستند، اما مطمئن شوید برای آنچه نیاز دارید پوشش دارید.
- پایش از دید مشتری، پیش از آنکه آنها لازم باشد به شما هشدار دهند، بینش لازم درباره هر مسئلهای را میدهد.
- پایش داخلی سیستمها میتواند بینشهایی درباره عملکرد بدهد تا تیم شما پیش از تبدیل مشکلات بالقوه به مشکلات واقعی از آنها جلوتر بیفتد.
- تناوب پشتیبانگیری شما تا حد زیادی به این بستگی دارد که داده شما چند وقت یکبار تغییر میکند و برای بازیابی چقدر باید به عقب برگردید.
- برای اعتبارسنجی پوشش پشتیبان، بازیابی باید بهطور دورهای تمرین شود.
- زیر نظر داشتن بودجه، هفتگی یا ماهانه، جلوی غافلگیریها را میگیرد.
چکلیست
چند مورد از موارد زیر را میتوانید ادعا کنید که پوشش دادهاید؟
- موجودی همه سختافزارها را همراه با گزارش نگهداری کامل ساختهاید
- قطعات یدکی سختافزاری موجود برای جایگزینی مؤلفههایی را فهرست کردهاید که از
گارانتی خارج شدهاند و ممکن است بهزودی خراب شوند
- برای بخشهای حیاتی سازمان خود قرارداد پشتیبانی تدوین کردهاید
- راهکارها را با نگاه از بیرون به داخل پایش کردهاید
- راهکارها را با زیر نظر گرفتن سنجههای داخلی پایش کردهاید
- پشتیبانگیری خودکار با آرشیوهای امن خارج از محل راهاندازی کردهاید
- بهطور دورهای پشتیبانگیری را از طریق بازیابی تأیید کردهاید
- هزینهکرد بودجه را دستکم ماهانه بازبینی کردهاید
خلاصه هوش مصنوعی
خلاصه فصل
نگهداری فنی و عملیاتی پلتفرم اغلب نادیده گرفته میشود تا زمانی که خرابی رخ دهد. فصل به سختافزار، پایش سلامت، پشتیبانگیری و بازیابی، قراردادهای پشتیبانی و مدیریت بودجه میپردازد. CTO باید مطمئن شود پشتیبانها واقعاً تست شدهاند و سیستمهای حیاتی پوشش دارند.
- پشتیبانگیری بدون تست بازیابی فقط امیدواری است، نه اطمینان.
- پایش پیشگیرانه از تبدیل مشکلات کوچک به بحران جلوگیری میکند.
- بدهی عملیاتی (legacy نادیدهگرفتهشده) مانند بدهی فنی است و نیازمند برنامه جایگزینی است.
این خلاصه با کمک هوش مصنوعی بر اساس محتوای فصل تهیه شده و جایگزین مطالعه کامل متن نیست.