مدیریت رخداد و پاسخ به خرابی
سامانه میافتد. این جمله را باید بهعنوان یک واقعیت پذیرفت، نه یک احتمال.
تفاوت سازمانها در این نیست که خرابی دارند یا نه. در این است که خرابی چند دقیقه طول میکشد یا چند ساعت، و اینکه بار دوم هم همان اتفاق میافتد یا نه.
ترتیبی که باید رعایت شود
مهمترین قاعدهٔ این حوزه و شکستهشدهترین آنها:
اول سرویس را برگردانید. بعد بفهمید چه شد.
وسوسهٔ طبیعی برعکس است. تیم فنی میخواهد بفهمد چرا، چون فهمیدن رضایتبخش است و برگرداندن بدون فهمیدن، ناقص به نظر میرسد.
اما هر دقیقهای که صرف تحلیل میشود، دقیقهای است که کاربر سرویس ندارد. اگر بازگرداندن نسخهٔ قبلی مشکل را حل میکند، همان کار را بکنید — حتی اگر ندانید چرا. لاگها و دادههای لازم برای تحلیل را نگه دارید و تحلیل را بعداً انجام دهید.
استثنا فقط یک مورد است: اگر ادامهٔ کار سامانه در حال خرابکردن داده است، خاموشی بهتر از سرویسدهی غلط است. سامانهای که فاکتور اشتباه صادر میکند یا دوبار پول برمیدارد، باید متوقف شود.
نقشها، حتی در تیم کوچک
در بحران، بدترین حالت این است که پنج نفر همزمان روی یک چیز کار کنند و هیچکس با مشتری حرف نزند. سه نقش کافی است و در تیم سهنفره هم قابل تفکیک است:
فرماندهٔ رخداد. تصمیم میگیرد و هماهنگ میکند. خودش دست به کد نمیزند — این بند مهم است، چون کسی که درگیر رفع مشکل شود، دیگر تصویر کلی را نمیبیند.
رفعکننده. یک یا دو نفر که واقعاً کار میکنند.
رابط اطلاعرسانی. با کسبوکار و مشتری در تماس است تا رفعکننده مجبور نباشد هر ده دقیقه جواب «چه خبر؟» را بدهد.
در تیم کوچک یک نفر میتواند دو نقش داشته باشد. آنچه نباید اتفاق بیفتد این است که هیچکس نقش اول را نداشته باشد.
سطحبندی شدت
بدون سطحبندی، یا برای هر چیزی همه را بیدار میکنید یا برای هیچچیز. هر دو بد است — اولی تیم را میسوزاند و دومی مشکل واقعی را دیر میکند.
سه سطح در عمل کافی است:
بحرانی. سامانه در دسترس نیست، یا داده در خطر است، یا پول اشتباه جابهجا میشود. پاسخ فوری، در هر ساعتی.
مهم. بخشی از کار نمیکند و راه جایگزین هست. در ساعات کاری، با اولویت.
عادی. آزاردهنده است، کار متوقف نشده. در نوبت عادی.
این سطوح باید در قرارداد پشتیبانی با زمان پاسخ مشخص بیایند، وگرنه هر تیکتی از نظر گزارشدهنده بحرانی است.
و یک نکته: سطح را بر اساس اثر بر کسبوکار تعیین کنید، نه بر اساس پیچیدگی فنی. باگی که فقط یک دکمه را خراب کرده ممکن است بحرانی باشد، اگر آن دکمه دکمهٔ پرداخت باشد.
چطور بفهمیم اتفاقی افتاده
بدترین راه ممکن، تماس مشتری است. یعنی خرابی مدتی طول کشیده و شما آخرین کسی هستید که فهمیدهاید.
حداقلی که هر سامانهٔ سازمانی باید داشته باشد:
- بررسی سلامت از بیرون شبکه، هر چند دقیقه.
- هشدار روی نرخ خطا، نه فقط روی خاموشی کامل. سامانهای که سی درصد درخواستها را رد میکند، از دید هر ابزار سادهای «بالا» است.
- هشدار روی صف کارهای پسزمینه. صفی که رشد میکند یعنی چیزی پردازش نمیشود، حتی اگر سایت باز شود. این را در کارهای پسزمینه گفتیم.
- هشدار روی فضای دیسک و اعتبار سرویسها. پیشپاافتادهترین علت خرابی در سامانههای سازمانی، و کاملاً قابل پیشگیری.
مبنای همهٔ اینها پایش و لاگ است. بدون آن، مدیریت رخداد یعنی حدسزدن جمعی.
و مسیر هشدار را امتحان کنید. هشداری که به کانالی میرود که کسی نگاهش نمیکند، وجود ندارد. سالی چند بار عمداً یک هشدار تولید کنید و ببینید واقعاً به کسی میرسد.
در حین رخداد
یک کانال واحد. همهٔ گفتوگو یک جا. اطلاعاتی که در پیام خصوصی رد و بدل شود، برای بقیه وجود ندارد و بعداً هم قابل بازخوانی نیست.
زماننگاری کنید. هر کاری که میکنید با ساعت بنویسید: «۱۴:۳۲ سرویس را ریاستارت کردیم.» در لحظه دردسر به نظر میرسد و در بازبینی، تنها چیزی است که واقعیت را نگه داشته. حافظه بعد از دو روز داستان میسازد.
تغییرات را یکییکی بدهید. اگر سه کار همزمان انجام دهید و مشکل حل شود، نمیدانید کدام بود. در بحران این وسوسه شدید است و باید مقاومت کرد.
اطلاعرسانی زودتر از حل. به کاربران بگویید مشکل را میدانید و در حال بررسیاید. سکوت، تیکت میسازد و اعتماد را بیشتر از خود خرابی خراب میکند.
بعد از رخداد: بازبینی بدون مقصر
اینجا جایی است که سازمان یا یاد میگیرد یا فقط میترسد.
بازبینی بدون مقصر یعنی فرض بگذارید هر کسی با اطلاعاتی که آن لحظه داشت، معقولترین کار را کرده. اگر کسی دستور اشتباهی روی سرور اصلی زد، سؤال این نیست که چرا حواسش نبود. سؤال این است که چرا سامانهای که یک اشتباه انسانی در آن همهچیز را میخواباند، اجازه داده بود چنین باشد.
دلیلش اخلاقی نیست، عملی است: در فرهنگ مقصریابی، آدمها خرابی را پنهان میکنند. و خرابی پنهان، خرابیای است که تکرار میشود.
سند بازبینی نباید بلند باشد. پنج بخش کافی است:
۱. چه اتفاقی افتاد و چه مدت طول کشید. ۲. اثرش بر کاربران و کسبوکار چه بود. ۳. خط زمانی، از اولین نشانه تا رفع. ۴. علتها — جمع، نه مفرد. رخداد جدی معمولاً چند لایه دفاعی را با هم رد کرده. ۵. کارهای بعدی، هر کدام با یک مسئول و یک تاریخ.
بند پنجم تنها بخشی است که ارزش دارد. بازبینیای که به کار قابل پیگیری ختم نشود، جلسهای بوده برای تخلیهٔ روانی. و آن کارها باید وارد همان تختهای شوند که بقیهٔ کارها هستند، وگرنه در فشار هفتهٔ بعد گم میشوند.
آمادهشدن، پیش از اینکه لازم شود
- دفترچهٔ کارهای متداول: ریاستارت سرویسها، پاککردن کش، بازگرداندن نسخه، بازیابی از پشتیبان. نوشته، نه در حافظهٔ یک نفر.
- فهرست تماس، شامل پیمانکارها و سرویسدهندهها. شمارهٔ پشتیبانی سرویس میزبانی را در ساعت سه صبح نباید جستوجو کرد.
- دسترسیهای اضطراری، از قبل تعریفشده. کسی که کلید ندارد نمیتواند کمک کند.
- تمرین. یک بار در سال، عمداً چیزی را در محیط آزمایش بشکنید و ببینید تیم چقدر طول میکشد. تقریباً همیشه معلوم میشود دفترچه ناقص است.
سنجههایی که ارزش دارند
دو عدد کافی است: چقدر طول میکشد تا بفهمیم و چقدر طول میکشد تا برگردد.
اولی کیفیت پایش را میسنجد، دومی آمادگی تیم را. هر دو باید روند نزولی داشته باشند. تعداد رخدادها سنجهٔ خوبی نیست — سامانهای که تغییر نمیکند رخداد کمی دارد و آن هم مرده است.