4 بهترین شیوه شبکه سازی که از قطع شدن شبکه Atlassian آموخته شد. ماه گذشته، فروشنده ابزارهای نرم افزاری Atlassian دچار قطعی شبکه شد که دو هفته به طول انجامید و بیش از 400 نفر از بیش از 200000 مشتری آنها را تحت تأثیر قرار داد. این قطعی باعث از بین رفتن چندین محصول آنها از جمله Jira، Confluence، Atlassian Access، Opsgenie و Statuspage شد.
در حالی که تنها تعداد کمی از مشتریان برای دو هفته کامل تحت تأثیر قرار گرفتند، این قطعی از نظر عمق مشکلات کشف شده توسط مهندسان شرکت و مدت زمانی که آنها برای یافتن و رفع مشکلات باید طی می کردند، قابل توجه بود. پشتیبانی شبکه در این دو هفته با مشکلات عدیده ای مواجه شد.
خطاهای داخلی و اشتباهات
این خاموشی نتیجه یک سری خطاهای داخلی ناگوار توسط کارکنان خود Atlassian بود و نه نتیجه یک حمله سایبری یا بدافزار. در پایان، هیچ مشتری بیش از چند دقیقه از تراکنش های داده خود را از دست نداد و اکثریت قریب به اتفاق مشتریان هیچ زمان خرابی را مشاهده نکردند.
نکته جالب در مورد کل وضعیت خاموشی Atlassian این است که چگونه آنها ارتباطات اولیه خود را از حادثه با مشتریان خود مدیریت کردند، و سپس چگونه آنها در نهایت یک پست وبلاگ طولانی منتشر کردند که جزئیات فوق العاده ای در مورد شرایط ارائه می دهد.
به ندرت پیش می آید که فروشنده ای که با چنین قطعی عظیم و عمومی مواجه شده باشد، تلاش کند تا به طور متفکرانه آنچه را که رخ داده و چرا اتفاق افتاده است، و همچنین نقشه راهی ارائه کند که دیگران نیز بتوانند از آن بیاموزند.
شرح جزئیات دقیق
در این پست، آنها زیرساخت‌های فناوری اطلاعات موجود خود را با جزئیات دقیق شرح می‌دهند، به کمبودهای برنامه بازیابی بلایای خود اشاره می‌کنند، به نحوه رفع کاستی‌های آن برای جلوگیری از قطعی‌های آینده اشاره می‌کنند، و جدول زمانی، گردش کار و روش‌هایی را که قصد دارند فرآیندهای خود را بهبود بخشند، شرح می‌دهند.
این سند صریح، واقعی و مملو از افشاگری های مهم است و باید برای هر مهندس و مدیر شبکه لازم باشد. باید به عنوان الگویی برای هر کسب‌وکاری که به نرم‌افزار وابسته است برای پیدا کردن و رفع اشتباهات مشابهی که ممکن است مرتکب شده باشید، استفاده شود، و همچنین به عنوان یک چارچوب بحث برای ارزیابی صادقانه کتاب‌های بازی بازیابی فاجعه شما باشد.
درس هایی از این حادثه گرفته شد
مشکل از زمانی شروع شد که شرکت تصمیم گرفت یک برنامه قدیمی را که با خرید یک نرم افزار مشابه از لحاظ عملکردی اضافه شده بود حذف کند. با این حال آنها این اشتباه را مرتکب شدند که دو تیم مختلف را با مسئولیت های جداگانه اما مرتبط تعیین کردند. یک تیم درخواست کرد که برنامه اضافی حذف شود، اما گروهی دیگر مسئول یافتن چگونگی انجام این کار شدند. که باید فوراً چند پرچم قرمز برافراشته می شد.
دو تیم از زبان و پارامترهای یکسانی استفاده نکردند و در نتیجه مشکلات ارتباطی فوری داشتند. به عنوان مثال، یک تیم از شناسه برنامه برای شناسایی نرم افزاری که قرار است حذف شود، استفاده کرد، اما تیم دیگر فکر کردند که در مورد شناسه کل نمونه ابری که برنامه ها در آن قرار دارند صحبت می کنند.
درس 1: ارتباطات داخلی و خارجی را بهبود بخشید
تیم هایی که درخواست تغییر شبکه می کنند و تیمی که در واقع آنها را اجرا می کند باید یکسان باشند. اگر نه، پس باید ابزارهای ارتباطی محکمی را برای اطمینان از همگام بودن آنها، با استفاده از زبان یکسان و دقت در رویه ها در محل قرار دهید. به دلیل ارتباط نادرست، مهندسان اطلسی برای چندین روز متوجه میزان اشتباه خود نشدند.
اما ارتباط بین تیمی تنها بخشی از مشکل بود. زمانی که Atlassian ارتباطات خود را بین مدیران مختلف و مشتریان خود تجزیه و تحلیل کرد، متوجه شدند که آنها جزئیات مربوط به قطع برق را ظرف یک روز در سیستم‌های نظارتی خود ارسال کرده‌اند، اما نمی‌توانستند مستقیماً به برخی از مشتریان خود دسترسی داشته باشند زیرا اطلاعات تماس زمانی که سایت های قدیمی حذف شدند و سایر اطلاعات به طرز غم انگیزی قدیمی بود.
به علاوه، داده های حذف شده حاوی اطلاعاتی بود که برای مشتریان لازم بود تا یک بلیط درخواست پشتیبانی معتبر را پر کنند. برای حل این مشکل، گروهی از توسعه دهندگان نیاز به ساخت و استقرار یک فرآیند فروش بلیط پشتیبانی جدید داشتند. این شرکت همچنین اعتراف می کند که باید زودتر در جدول زمانی قطعی تماس می گرفتند و منتظر نمی ماندند تا تصویر کاملی از دامنه فرآیندهای بازیابی داشته باشند.
این به مشتریان این امکان را می داد که حتی بدون بازه زمانی مشخص، برنامه ریزی بهتری در مورد حادثه داشته باشند. “ما باید عدم اطمینان خود را در ارائه تاریخ بازسازی سایت زودتر می پذیرفتیم و زودتر خود را برای گفتگوهای حضوری در دسترس قرار می دادیم تا مشتریان ما بتوانند بر اساس آن برنامه ریزی کنند. ما باید در مورد آنچه که در مورد قطع برق می‌دانیم و آنچه نمی‌دانیم شفاف می‌بودیم.»
درس 2: از داده های مشتری محافظت کنید
با داده‌های مشتری خود با احتیاط رفتار کنید، مطمئن شوید که آنها به‌روز و دقیق هستند و در مکان‌های مختلف و جداگانه پشتیبان‌گیری شده‌اند. مطمئن شوید که داده‌های مشتری شما می‌توانند از یک فاجعه جان سالم به در ببرند و چک‌های خاصی را در هر کتاب بازی بگنجانید.
این نکته دیگری را در مورد بازیابی فاجعه نشان می دهد. در طول قطعی ماه آوریل، Atlassian اهداف زمان بازیابی خود را از دست داد (بدیهی است که با توجه به هفته‌هایی که برای بازیابی سیستم‌ها صرف شده بود)، اما موفق شد به اهداف نقطه بازیابی خود برسد، زیرا آنها توانستند داده‌ها را فقط چند دقیقه قبل از قطع واقعی بازیابی کنند. آنها همچنین راهی برای انتخاب مجموعه‌ای از سایت‌های مشتری و بازیابی تمام محصولات به هم پیوسته خود از پشتیبان‌گیری به یک لحظه قبلی در زمان به هر روش خودکار نداشتند.
آنها در تجزیه و تحلیل خود نوشتند: «حذف‌های سطح سایت ما که در ماه آوریل اتفاق افتاد، دارای ران‌بوک‌هایی نبودند که بتوانند به سرعت برای مقیاس این رویداد خودکار شوند. ما توانایی بازیابی یک سایت را داشتیم، اما قابلیت‌ها و فرآیندهایی برای بازیابی تعداد زیادی از سایت‌ها ایجاد نکرده بودیم.
در اعترافات وبلاگ، آنها روند مدیریت حادثه در مقیاس بزرگ قبلی خود را ترسیم می کنند – می توانید ببینید که قطعات متحرک زیادی دارد و در حد وظیفه “کنترل عمق، گستردگی و مدت حادثه آوریل” نبود.
درس 3: سناریوهای پیچیده بازیابی فاجعه را آزمایش کنید
برنامه‌های بازیابی فاجعه، کتاب‌های بازی، و رویه‌های خود را بررسی و دوباره بررسی کنید تا مطمئن شوید که اهداف مختلف را برآورده می‌کنند. مطمئن شوید که سناریوها را در تمام اندازه‌های زیرساخت مشتری آزمایش کرده‌اید. این به معنای پرداختن و پیش‌بینی واکنش رویداد در مقیاس بزرگ‌تر و درک روابط پیچیده مختلف مشتریانی است که از چندین محصول استفاده می‌کنند یا به یک سری و توالی برنامه‌های کاربردی شما وابسته هستند.
اگر از اتوماسیون استفاده می‌کنید، مطمئن شوید که APIهای شما به درستی کار می‌کنند و سیگنال‌های هشدار مناسب را در صورت عدم عملکرد ارسال می‌کنند. این یکی از مسائلی بود که اطلسیان مجبور بود در حالی که روزها طول کشید، آن را رفع اشکال کند.
درس 4: از داده های پیکربندی محافظت کنید
در نهایت، این مسئله در مورد نحوه حذف داده ها وجود دارد که باعث شروع کل قطعی شد. آنها اکنون متوجه شده اند که حذف داده ها، به خصوص کل سایت، نباید مجاز باشد. Atlassian در حال حرکت به سمت چیزی است که آنها آن را “حذف نرم” می نامند، که بلافاصله داده ها را از بین نمی برد تا زمانی که با بازگردانی های تعریف شده سیستم بررسی شود و از تعدادی حفاظتی عبور کند.
Atlassian در حال ایجاد یک سیاست “حذف نرم جهانی” در تمام سیستم های خود و ایجاد یک سری استانداردها و بررسی های داخلی است. گزینه soft delete چیزی بیش از یک گزینه است. هیچ داده پیکربندی را تا زمانی که آن را در سراسر زیرساخت خود آزمایش نکرده اید حذف نکنید.
نظر خود را به اشتراک بگذارید