Ви задеплоїли в п'ятницю о 17:00. Ви знали, що міграція не пройшла на staging — тобто на копії продакшену, де все тестується перед тим, як побачать реальні користувачі. Ви сказали собі, що робили це сотню разів. О 17:47 база даних залочилась. О 18:12 задзвонив телефон. Суботу ви витратили на те, що можна було запобігти за дві хвилини. 📋
Я знаю це, бо сам був тією людиною. І тому що кожен ops-ретроспектив, який я читав, розповідає ту саму історію: хтось пропустив крок, про який знав.
Пілот, річка та чеклист
15 січня 2009 року капітан Чеслі Салленбергер посадив рейс US Airways 1549 на річку Гудзон. Обидва двигуни відмовили після зіткнення зі зграєю гусей. Усі 155 людей вижили. Коли журналісти запитали як, він не сказав 'досвід' чи 'інтуїція'. Він сказав, що його екіпаж дотримувався чеклистів. Чеклист відмови обох двигунів. Чеклист аварійної посадки на воду. Крок за кроком, під максимальним тиском.
Авіація робить це з 1935 року, коли тестовий політ Boeing Model 299 розбився, бо пілот забув зняти блокування керування. Літак — прототип чотиримоторного бомбардувальника — був буквально занадто складним для пам'яті однієї людини. Відповідь Boeing була не 'наймайте кращих пілотів', а простий чеклист на картці. Аварійність впала. Індустрія більше не озиралась назад.
Ваш продакшен-деплой — процес доставки нового коду на сервери, якими реально користуються люди — не менш складний, ніж передпольотна перевірка бомбардувальника 1935 року. Ваше реагування на інциденти не менш критичне, ніж аварійна посадка на воду. Але ви досі покладаєтесь на пам'ять, досвід і 'ми завжди так робили'.
Чому розумні люди пропускають кроки
Це не про інтелект. Це про те, як працює мозок.
Хірурги, які використовують чеклисти, зменшують ускладнення на 35% і смертність на 47%, згідно з визначним дослідженням ВООЗ 2009 року в New England Journal of Medicine. Це люди з десятиліттям медичної освіти. Вони пропускають кроки не через недбалість — вони пропускають кроки, бо робоча пам'ять людини ламається під послідовним навантаженням.
Атул Ґаванде, хірург, який написав The Checklist Manifesto, виділив два типи помилок:
Помилки незнання: ви не знаєте, що робити. Їх стає менше, бо знання поширюються онлайн.
Помилки невиконання: ви точно знаєте, що робити, але не виконуєте. Їх стає більше, бо системи ускладнюються. Знання є. Виконання розсипається.
У техі майже кожний продакшен-інцидент, який я розслідував, був помилкою невиконання. Хтось знав, що потрібно запустити міграцію бази даних — скрипт, який оновлює структуру бази відповідно до нового коду — перед деплоєм. Хтось знав, що потрібно перевірити план відкату — задокументовані кроки для повернення до попередньої робочої версії, якщо все зламається. Хтось знав, що потрібно перевірити feature flag — перемикач, який ховає нову функціональність, поки ви не будете готові.
Вони знали. Вони забули. О 23:00, після 10-годинного дня, вони пропустили крок 7 із 12, бо мозок прошепотів 'я робив це сотню разів'. 🫶
Три чеклисти, які потрібні кожній техкоманді
Ось система. Три чеклисти. Кожен цілиться в конкретний момент, коли людська пам'ять відмовляє найчастіше.
Чеклист 1: Деплой-чеклист
Запускається перед кожним продакшен-деплоєм. Кожен пункт бінарний — так чи ні. Ніяких оціночних суджень. Якщо хоч один пункт 'ні' — зупиняєтесь. В авіації одне 'ні' не дає літаку злетіти. Ваші деплої заслуговують такої ж поваги.
## Pre-Deploy
- [ ] Усі тести пройшли на staging
- [ ] Міграції бази даних протестовані на staging
- [ ] План відкату задокументований і перевірений
- [ ] Feature flags перевірені (нове вимкнено за замовчуванням)
- [ ] Дашборди моніторингу відкриті
- [ ] On-call інженер підтвердив доступність
- [ ] Вікно деплою підтверджене (не п'ятниця 17:00)
- [ ] Зміна анонсована в командному каналі
- [ ] Метрики попереднього деплою стабільні 24+ години
## Post-Deploy Verification
- [ ] Health check endpoints повертають 200
(200 = відповідь сервера 'я в порядку')
- [ ] Error rate не підвищений відносно baseline
- [ ] Ключові користувацькі сценарії перевірені вручну
- [ ] Метрики продуктивності в нормі
- [ ] Деплой записаний у changelog
Моя команда впровадила цей чеклист 18 місяців тому. Інциденти, пов'язані з деплоєм, впали з приблизно одного кожні два тижні до одного кожні три місяці. Не тому, що ми стали розумнішими. Тому що перестали пропускати кроки. ⚙️
Чеклист 2: Чеклист реагування на інциденти
Коли продакшен ламається, ваш мозок переходить у режим 'бий або тікай'. Адреналін зашкалює. Хочеться полагодити ЗАРАЗ. Саме тоді чеклисти важливі найбільше — бо префронтальна кора, відповідальна за послідовне мислення, вимикається першою під дією адреналіну.
## Хвилина 0-5: Оцінка
- [ ] Підтвердити, що інцидент реальний (не фальшива тривога моніторингу)
- [ ] Severity: S1 (повний аутедж), S2 (частковий), S3 (деградація)
- [ ] Призначити incident commander (одна людина приймає рішення)
- [ ] Відкрити окремий канал інциденту
## Хвилина 5-15: Комунікація
- [ ] Status page оновлена
- [ ] Постраждалі клієнти повідомлені (якщо S1/S2)
- [ ] Внутрішні стейкхолдери повідомлені
- [ ] ETA наступного апдейту повідомлено
(навіть якщо це просто 'ми розбираємось')
## Хвилина 15+: Фікс
- [ ] Root cause визначено АБО запущена ескалація
- [ ] Фікс протестований на staging (якщо можливо)
- [ ] Фікс задеплоєний на продакшен
- [ ] Моніторинг підтверджує вирішення
## Після інциденту
- [ ] Post-mortem запланований протягом 48 годин
- [ ] Таймлайн задокументований, поки пам'ять свіжа
- [ ] Action items призначені з відповідальними і дедлайнами
- [ ] Чеклист оновлений, якщо бракувало кроку
Останній пункт — тихий двигун усієї системи. Кожен інцидент стає зворотним зв'язком для чеклиста. Щось пропущено? Додай. Щось зайве? Прибери. Чеклист живий — він вчиться на кожній помилці, щоб вам не довелось їх повторювати. 🧘
Чеклист 3: Чеклист код-рев'ю
Код-рев'ю — коли колега читає ваш код перед тим, як він потрапить на продакшен — без чеклиста це читання і надія. З чеклистом — це систематична перевірка того, що конкретних категорій проблем не існує.
## Безпека
- [ ] Жодних захардкоджених credentials, API keys чи tokens
- [ ] Введення користувача валідоване і санітизоване
- [ ] Запити до бази використовують параметризовані стейтменти
(запобігає SQL injection — атаці, коли хтось
підсовує команди до бази через форму логіну)
- [ ] Автентифікація перевірена на всіх захищених endpoints
(endpoint = конкретний URL, на який відповідає ваш додаток)
## Надійність
- [ ] Обробка помилок покриває failure cases
- [ ] Зовнішні API-виклики мають встановлені timeouts
(API = спосіб програмам спілкуватися між собою)
- [ ] Запити до бази мають індекси для великих таблиць
(індекс = швидкий пошук, як покажчик у книзі)
- [ ] Немає N+1 запитів (вибірка пов'язаних даних по одному
рядку замість одного ефективного батчу)
## Підтримуваність
- [ ] Функції роблять одну справу
- [ ] Назви змінних описують те, що вони зберігають
- [ ] Складна логіка має коментарі, що пояснюють ЧОМУ
- [ ] Тести покривають нові шляхи коду
Як зробити так, щоб чеклисти прижилися
Створити чеклист легко. Складна частина — та, про яку ніхто не говорить — це запобігти забуванню. Чотири правила:
Зробіть їх обов'язковими, не опціональними. Вбудуйте чеклист у ваш deploy pipeline — автоматизовану послідовність кроків, яка збирає і доставляє код. Кнопка деплою залишається сірою, поки кожен пункт не позначений. Чеклист, який 'рекомендовано', використовується у 80% випадків — а це означає, що він провалюється саме тоді, коли потрібен найбільше: під тиском, вночі, коли ви втомлені.
Тримайте їх короткими. Дослідження в авіації показали, що чеклисти більше ніж 9 пунктів різко втрачають в дотриманні. Якщо у вашому 30 пунктів — розбийте на фази. Кожна фаза: 5-9 пунктів. Короткий чеклист, якого дотримуються, б'є довгий, який ігнорують.
Переглядайте щоквартально. Прибирайте пункти, які ніколи нічого не ловлять. Додавайте пункти з нещодавніх інцидентів. Застарілий чеклист породжує зневагу — люди перестають сприймати його серйозно, коли половина пунктів не стосується їхнього поточного стеку.
Зробіть їх видимими. Закріпіть у командному каналі. Вбудуйте в UI деплой-інструменту. Роздрукуйте і прикріпіть біля моніторів. Найкращий чеклист — той, який ви бачите, не шукаючи.
Скільки це коштує
Будемо чесними щодо компромісів. Чеклисти додають тертя. Деплой-чеклист додає 5-10 хвилин до кожного деплою. Чеклист реагування на інциденти відчувається болісно повільним, коли продакшен горить. Чеклисти код-рев'ю подовжують рев'ю.
Це тертя — і є суть. Це свідоме сповільнення в моментах, коли швидкість завдає шкоди. Пілот не поспішає з передпольотною перевіркою, бо пасажири вже на борту. Ви не повинні поспішати з деплоєм, бо PM попросив до кінця дня.
Інша ціна — підтримка. Чеклист без підтримки гірший за відсутність чеклиста — він вчить вашу команду, що процес — це театр. Хтось має бути відповідальним за кожен чеклист, переглядати його щоквартально і оновлювати після кожного інциденту. Це реальна робота.
Тепер ви озброєні
Пам'ятаєте той п'ятничний деплой? Той, де ви пропустили перевірку на staging і витратили суботу на відновлення бази даних?
Тепер у вас є три чеклисти, які запобігають саме таким провалам. Не через дисципліну, не через силу волі — через систему, яка виходить з того, що ваш мозок відмовить під тиском, і перехоплює це до того, як буде пізно.
Чеклисти — це не про дисципліну. Це про смирення. Визнання того, що ваш мозок — яким би гострим він не був — не здатен надійно виконати 15 послідовних кроків під стресом, не пропустивши жодного. Пілоти це знають. Хірурги це знають. Астронавти це знають.
Тех — єдина індустрія, де досвідчені професіонали досі кажуть 'мені не потрібен чеклист, я робив це тисячу разів'. Це не впевненість. Це фраза, яка передує кожному інциденту, якого можна було уникнути.
Напишіть чеклист. Дотримуйтесь чеклиста. Оновлюйте чеклист. Ваш продакшен подякує. І та людина, яку розбудять о 2 ночі, теж — а цією людиною можете бути ви. 🛁
