Как да се справите с продукционна авария: наръчник за малки екипи

При авария техническият проблем рядко е трудната част. Координацията е. Ето последователността, която пази малкия екип да не влоши нещата.

Повечето малки екипи се справят зле с първата си сериозна авария — не от некомпетентност, а защото всички дебъгват едновременно, никой не говори с клиентите и двама души пускат противоречиви поправки. Наръчникът по-долу съществува, за да предотврати това.

Първите десет минути

1. Обявете я. Кажете думата «инцидент» на глас в екипния канал. Двусмислието дали това е сериозно струва повече време от всяка техническа стъпка.
2. Определете водещ на инцидента. Един човек, изрично. Той не дебъгва — координира, решава и води хронологията.
3. Оценете радиуса на поражение: кой е засегнат, движат ли се пари погрешно, застрашени ли са данни. Това определя всичко останало.
4. Спрете кръвотечението, преди да търсите причината. Rollback, изключване на функцията, страница за поддръжка. Разбирането може да почака; въздействието върху клиента — не.
5. Публикувайте съобщение за статус. Дори «разследваме» бие мълчанието — мълчанието превръща аварията в проблем с доверието.

Роли, дори в екип от четирима

В малък екип един човек може да носи две роли — но водещият на инцидента и разследващият никога не бива да са едно и също лице при сериозен инцидент.

Какво да казвате на клиентите

• Потвърдете бързо, дори без отговори — «знаем за проблема и разследваме» в рамките на минути
• Заявете въздействието с техни думи: какво не могат да направят сега, а не коя услуга е деградирала
• Дайте час за следващо обновление и го спазете, дори ако нищо не се е променило
• Никога не спекулирайте за непотвърдена причина — опроверженията струват повече доверие, отколкото би струвало мълчанието
• Кажете ясно, когато е решено, и добавете писмено обяснение, ако въздействието е било съществено

След това: частта, която всички пропускат

Постмортем в рамките на 48 часа, докато паметта е точна. Без обвинения — не от учтивост, а защото обвиненията карат хората да скриват информация и следващият инцидент става по-труден за предотвратяване.

• Хронология: какво се случи, кога, кой какво направи — само факти
• Въздействие: продължителност, засегнати потребители, последици за пари или данни
• Допринасящи фактори, в множествено число — една-единствена първопричина почти винаги е опростяване
• Задачи със собственици и дати; точки без двете са украса
• Какво мина добре — засичането или реакцията, които сработиха, си заслужава да се подсилят

Не се издигате до нивото на своя план за реакция при инциденти. Падате до нивото на онзи, който наистина сте упражнявали.

Подготовка, преди да се случи

• Алармиране по симптоми, които клиентите усещат (плащането се проваля), а не само по инфраструктурни метрики (висок CPU)
• Rollback, който е една команда и е репетиран в спокойни условия
• Статус страница, която съществува, преди да ви потрябва
• Писмена ескалация: на кого се звъни в 3 сутринта и на кого, ако той не вдигне
• Едно учение — счупете нещо нарочно в staging и минете по наръчника

Потвърдете възстановяването с реални сценарии

По-малко грешки могат да прикриват несъгласувани данни. Определете доказателствата преди приключване на инцидента.

1. Запишете въздействие, последно работещо състояние и скорошни промени.
2. Изберете обратимо действие с отговорник и условие за спиране.
3. Проверете основни пътища, забавени задачи и сверяване на данни.

• реакция при производствени инциденти →
• postmortem добри практики →