Сповіщення спрацьовує о 02:10. Інженер надсилає зміну конфігурації, служба оформлення замовлення починає повертати помилки, а черговий керівник скасовує її через 40 хвилин. На нараді з перегляду перше питання: «Хто надсилав зміни?» За лічені хвилини розмова зводиться до думки однієї людини о 2-й годині ночі, і ніхто не запитує, чому зміна змогла потрапити у виробництво без попереднього повідомлення, чому сповіщення так довго завантажувалося на сторінки або чому комплект завдань застарів.
Це ілюстративний сценарій, а не випадок клієнта. Його легко впізнати, бо він трапляється саме так: огляд інциденту, який зосереджується на останній особі, що діяла, створює акуратну історію та дуже мало уроків.
Цей посібник призначений для керівників інженерних відділів та керівників відділів розвитку, які хочуть, щоб люди навчилися краще аналізувати дані про інциденти та узгоджувати покращення, які можна протестувати. У ньому розглядається, як відокремити прогалини в навичках від навколишніх умов, як розробляти практику, як проводити обговорення та як вимірювати ефективність оцінювання.
Що означає і що не означає слово «бездоганний»
Книга Google «Інженерія надійності сайтів» чітко сформульована: щоб аналіз був справді бездоганним, він має зосередитися на визначенні причин, що сприяли інциденту, без звинувачень будь-якої особи чи команди у поганій чи неналежній поведінці. У ній також описується припущення, що лежить в основі: усі причетні діяли з добрими намірами та правильно вчинили з наявною інформацією.Книга Google SRE «Посмертна культура: навчання на невдачах».)
Безвинність не означає відсутність наслідків. У тому ж розділі очікується, що розтин завершиться завданнями з пріоритетом та відповідальним. Безвинність розслідування все ще вимагає відповідальності, але ця відповідальність переходить від «хто це спричинив» до «хто зробить систему безпечнішою і до якого терміну». Якщо ваші огляди пропускають другу половину, у вас приємна розмова, а не процес навчання.
1. Визначте поведінку та її контекст
Почніть із конкретної поведінки, яку ви хочете змінити. Фраза «Наші огляди інцидентів зосереджені на останній людині, яка діє» – це помітно. «Наша культура базується на звинуваченнях» – ні.
Тоді запитайте себе, чи це взагалі проблема з навичками. Тренування можуть виправити лише деякі причини низької продуктивності. Перш ніж щось створювати, виділіть три можливості:
- Відсутня навичка. Рецензенти не знають, як побудувати часову шкалу, відрізнити тригер від фактора, що сприяє, або запитати: «що зробило цю дію розумною на той момент?»
- Стимулювання. Відгуки враховуються в обговореннях ефективності, тому люди формують свої облікові записи так, щоб захистити себе.
- Градієнти авторитету та минулі реакції. Молодший інженер, який висловив занепокоєння минулого кварталу і якому сказали припинити негативну реакцію, не висловить його на цій зустрічі, якою б добре він не був навчений.
Тільки перша проблема — це проблема навчання. Дві інші — це умови. Якщо ви тренуєте навичку, а умови не змінюєте, люди будуть повторювати те, що карає робоче місце. Ставтеся до свого поточного погляду на причину як до гіпотези та перевірте її за допомогою кількох розмов з інженерами та перегляду нещодавніх оглядових документів, перш ніж вирішуватимете взятися за програму.
2. Встановіть робочі умови для практики
Практика переходить до іншого формату, лише якщо на неї відповідає працівник. Перш ніж хтось почне репетирувати, узгодьте наступне з людьми, які проводять огляди:
- Затверджені обов'язки. Хто координує, хто пише графік, хто відповідає за подальші дії? Чітко визначте ролі, щоб координатор не імпровізував, використовуючи свої повноваження.
- Як лідери сприймають занепокоєння. Якщо інженер каже: «Інструмент розгортання дозволив мені уникнути канарейки», що робить директор далі? Визначте відповідь заздалегідь, наприклад: подякуйте йому, зареєструйте це як фактор, що сприяє, і призначте дію.
- Відповідь керівника. Репетиція персоналу потребує відповідної реакції керівника. Якщо ви навчаєте інженерів висловлюватися під час оглядів, але їхні менеджери все одно запитують: «Чия це вина?», навчання програє.
Короткий інструктаж для менеджерів щодо процесу оцінювання є таким же важливим, як і навчання для учасників. Включіть чіткий виклад того, як документи з оцінювання використовуються та не використовуються в управлінні ефективністю.
3. Розробіть навчальну подорож, засновану на поведінці
У рекомендаціях Центру Карнегі-Меллона Еберлі щодо цілей навчання робиться корисний акцент на тому, що цілі, оцінювання та навчальні стратегії повинні бути узгоджені одне з одним (Центр Еберлі, цілі навчання). Це керівництво з розробки, а не докази щодо якогось конкретного інструменту чи результату, але це хороший тест для цієї програми: якщо метою є аналіз доказів та узгодження покращень, які можна перевірити, то самі лише питання для повторення не можуть бути оцінкою.
Таксономія Блума допомагає тут описати когнітивну вимогу завдання: аналізувати, оцінювати, створювати. Вона описує, що саме завдання вимагає від людини. Вона не пояснює, чому вона це робить чи не робить, тому не використовуйте її для діагностики мотивації.
Практична подорож має три етапи.
| Стажування | Дія учня | Доставка |
|---|---|---|
| Підготовка | Ознайомтеся з політикою перевірки інцидентів та коротким глосарієм (тригер, фактор, що сприяє, пом'якшення, пункт дії). Коротка діагностична перевірка необхідних умов. | Самостійне навчання. Перевірка знань підтверджує лише передумови, а не навички. |
| Практика | Проаналізуйте підготовлений випадок інциденту та узгодьте покращення, які можна перевірити. Потрібна обґрунтована відповідь, а не вибір із кількох варіантів. | Інтерактивна або фасилітована практика з розгляду кейсів зі зворотним зв'язком щодо якості аналізу факторів, що сприяють, та подальших дій. |
| Перегляд та передача | Обговоріть один неоднозначний вибір, а потім завершіть нову справу або реальний огляд під наглядом. | Живий коучинг або асинхронний огляд. Перевірте передачу після того, як люди матимуть час використати навичку на роботі. |
Зберігайте реалістичність кейсу та доручіть його перевірку досвідченому інженеру. Технічно неправильний кейс вчить рецензентів не довіряти вправі.
4. Опрацювання сценарію та його аналіз
Ось як може проходити практичний сеанс за сценарієм 02:10. Пакет доказів містить журнал розгортання, часову шкалу сповіщень, політику підкачки, запит на зняття та робочий модуль – усе це вигадано.
Підказка для учасника. «Поясніть, чому інженер наполягав на зміні саме тоді, коли це було зроблено. Наведіть докази, які ви використовували. Розкажіть нам, яка додаткова інформація чи підтримка вам знадобиться, перш ніж ви зможете бути впевненими».
Слабка відповідь звучить приблизно так: «Інженер мав би перевірити стадію». У ній називається людина, нічого не цитується і жодних змін не пропонується.
Більш переконлива відповідь звучить так: «Журнал розгортання показує, що зміна була внесена безпосередньо, оскільки крок canary є необов’язковим у інструменті. Запит на зняття мав одного рецензента, який схвалив його після 20-хвилинного вікна. Сторінка запустилася через 18 хвилин після початку помилок, оскільки поріг сповіщення було встановлено на п’ятихвилинне середнє значення. Я хотів би знати, скільки інших змін цього місяця пропустили canary, і чи повідомляли коли-небудь черговим інженерам, що крок можна пропустити. Пропоновані дії: зробити canary обов’язковим для цього рівня обслуговування, власник: команда платформи, перевірка: спроба розгортання skipped-canary на стадії підготовки та підтвердження його блокування; зменшення вікна сповіщення, власник: керівник чергового процесу, перевірка: повторення помилок минулого тижня відносно нового порогу».
Зверніть увагу, що робить його кращим. Він використовує докази, називає обмеження та невизначеність, а також завершується діями, які можна перевірити.
А тепер підбиття підсумків. Не просто оцінюйте. Запитайте:
- Що підтверджували докази, і що ви припускали?
- Які з ваших дій команда насправді мала б право виконати?
- Що полегшило б повторення такої поведінки у вашому наступному справжньому огляді? Що ускладнило б це?
Третє питання найважливіше. Воно висвітлює умови з розділу 2. Якщо троє учасників кажуть: «Мій менеджер запитає, хто це зробив», ви виявили, що обмеження, яке навчання не може усунути.
5. Вимірювання поведінки та виконання встановлених цілей
Ключове питання полягає в тому, які докази свідчать про те, що учні можуть аналізувати дані інцидентів та узгоджувати перевірені покращення. Ось рубрика, з якої можна почати. Це пропозиція адаптації з досвідченим інженером, а не перевірений стандарт готовності.
| критерій | Спостережувані докази | 0 | 1 | 2 |
|---|---|---|---|---|
| Виконання завдання | Аналізує докази та погоджує покращення; фіксує дії та докази, що стоять за ними | Відсутній або непідтримуваний | Частково, з відповідними пропусками | Повне та обґрунтоване відповідно до узгоджених критеріїв |
| Обґрунтування | Пояснює обмеження, альтернативи та невизначеність; фактори, що сприяють цьому, виходять за рамки останньої дії | Відсутній або непідтримуваний | Частково, з відповідними пропусками | Повне та обґрунтоване |
| Межі | Використовує затверджені процедури; просить про допомогу, коли інформація або повноваження відсутні | Відсутній або непідтримуваний | Частково, з відповідними пропусками | Повне та обґрунтоване |
Визначте критичні помилки окремо, наприклад, назвавши особу як причину або запропонувавши дію без відповідальності. Високий загальний бал ніколи не повинен приховувати критичну невдачу.
Для самого вимірювання:
- Якість аналізу факторів, що сприяють. Порівняйте відгуки, написані до програми, з відгуками, написаними після, оціненими за тією ж рубрикою кимось, хто не знає, що є що. Використовуйте як невідомі, так і реальні випадки подальшого спостереження.
- Доведення до кінця. Підрахуйте частку пунктів дії, які мають власника, тест та були виконані, від усіх порушених пунктів дії. Вкажіть знаменник та часовий проміжок.
- Поєднуйте спостереження зі змінами в процесі. Скористайтеся справжнім оглядом. Перевірте, що сталося з пунктами дій після цього.
Будьте обережні з обсягом звітів. Якщо після програми реєструється більше проблем та майже помилок, це може означати, що покращилася безпека, зросла довіра або новий інструмент спростив ведення журналу. Падіння може означати менше проблем або менше бажання говорити. Перш ніж пояснювати будь-який рух навчанням, зверніть увагу на те, що змінилося за той самий період, і уникайте заяв про розмір ефекту, який ви не виміряли.
Вищезазначені рекомендації Еберлі щодо узгодження фреймів не є доказом того, що цей підхід зменшує кількість інцидентів. Зберігайте власні базові та подальші дані та розглядайте їх як локальні докази.
Які обмеження можуть залишатися навіть після покращення навичок
Будьте відвертими щодо наступного зі спонсорами:
- Документи з огляду все ще можуть враховуватися при прийнятті рішень щодо ефективності.
- Команди, що перебувають під тиском виконання, можуть пропускати дії, які є дорогими, але розумними.
- Дії між командами можуть зупинитися, оскільки ніхто не володіє межею поля.
- Старші інженери можуть все ще домінувати в дискусії.
Кращий аналіз не усуває їх. Плануйте окремі зміни в процесах для них.
Втілення цього на практиці з AhaSlides
AhaSlides підтримує адаптивне навчання, інтерактивне навчання та перехід між живим виступом та виступом у власному темпі. У цьому випадку це може означати етап підготовки у власному темпі, живий або фасилітований кейс-сеанс із відкритими підказками для відповіді, щоб кожен зобов'язався провести аналіз перед обговоренням у групі, та подальше завдання після сеансу. Конкретні функції авторства, оцінювання та звітності слід перевірити в демонстрації на вашому власному кейсі, перш ніж покладатися на них, а все, що стосується штучного інтелекту, симуляторів або інтеграції з вашими інструментами для роботи з інцидентами, слід розглядати як зовнішнє, доки не буде показано.
Наступний крок: Візьміть наведену вище рубрику та адаптуйте її разом із одним зі своїх старших інженерів, а потім створіть кейс, який ви використовуватимете. Якщо ви хочете побачити, як може працювати ця подорож у реальному часі у власному темпі, забронюйте демонстрацію робочого процесу AhaSlides як тільки ви складете чернетку справи та рубрики.
