Як пояснити рішення про повернення англійською мовою

Рішення про відновлення часто є легкою частиною - пояснення цього рішення чітко, як в момент, так і після, є тим, що визначає, чи довіряє команда виклику і вивчає правильний урок з нього, замість того, щоб бути збентеженим тим, що насправді сталося.

Ключовий словник

** Відновлення ** — повернення системи до попереднього стану, зазвичай, за допомогою повторного розгортання попередньої версії. Використовується, коли нове розгортання спричиняє проблеми, і найшвидшим безпечним шляхом є скасування розгортання, а не його виправлення. “Ми повертаємось до попередньої версії, а не намагаємося залагодити це в виробництві — кількість помилок піднімається настільки швидко, що повернення швидше і безпечніше, ніж зневадження в реальному часі.”

** Перенесення вперед ** — альтернатива відновленню: виправлення проблеми за допомогою нового розгортання замість повернення до старого, зазвичай вибирається, якщо виправлення невелике, добре зрозуміле і швидше, ніж повне відновлення. “Враховуючи те, наскільки ми близькі до фактичного виправлення, ми рухаємося вперед, а не назад — відновлення також скасує три інші виправлення, які були доставлені в цьому ж розгортанні, які ми не хочемо втратити.”

** Відомий стан ** — певна попередня версія або налаштування, які підтверджено як працюючі, ціль повернення, відмінна від просто « попередньої версії », яка також може бути небезпечною. “Перед тим, як ми повернемо, давайте перевіримо, чи є цільова версія насправді у стані «відомо-хороший» — версія, що була неподалік від цієї, мала свою власну, не пов’ язану з цим проблему, яку ми залатали два дні тому.”

** Обґрунтування рішення ** — явне обґрунтування виклику rollback (або roll- forward), заявлене достатньо чітко, щоб хтось, хто переглядає його пізніше, розумів, чому цей вибір був зроблений, враховуючи те, що було відомо на той час, а не лише те, що було вирішено. “Розуміння рішення тут було: виправлення ще не було повністю зрозуміло, рівень помилок активно піднімався, і відновлення було відомою безпечною дією - відновлення купило нам час, щоб насправді зрозуміти кореневу причину без клієнтів, які переживають постійні помилки.”

Звичайні фрази

• «Ми повертаємося назад — ось конкретна причина і до якого стану ми повертаємося»
• Чи є цей процес насправді швидшим, чи ми недооцінюємо його?»
• Чи підтверджено, що ця цільова версія є добре відомою державою?»
• «Яка логіка рішення, щоб ми могли переглянути його чітко в постмортемі?»
• «Хто робить дзвінок, і який час для цього рішення?»

Приклади висловлювань

Оголошування рішення про відновлення під час інциденту: “Ми повертаємо службу замовлення до попередньої версії, розгорнутої о 14:14 і підтвердженої стабільною за два тижні до цього. Частота помилок зросла до 8% з часу останнього розгортання о 15:40, і ми ще не розуміємо причину достатньо добре, щоб безпечно продовжувати. Відновлення в процесі, ETA п’ять хвилин.”

Пояснення, чому було обрано перенесення вперед:

• “Ми вирішили не повертати назад — проблема полягає в одній нульовій перевірці, яку ми повністю розуміємо, і повернення також скасує два інші виправлення, які були вбудовані в це розгортання, з яких користуються клієнти. Ми рухаємося вперед з цільовим виправленням замість цього, очікуємо в найближчі десять хвилин.”*

Я пишу обґрунтування в пост-мортальний:

• “Розрахунок рішення: на той час, ми не мали підтвердженої кореневої причини і частота помилок активно зростала. Відновлення до відомого стану було найменш ризикованою дією, навіть якщо це означало тимчасову втрату двох невеликих можливостей з цього випуску. З погляду на минуле, це був правильний вибір, враховуючи те, що було відомо о 3:45 вечора. “*

Професійні поради

• Явно вкажіть ціль rollback, включаючи підтвердження, що це справді відомий- хороший стан — «відновлення» без вказівки, що залишає місце для повернення до версії з власною окремою проблемою.
• Обґрунтуйте рішення прокрутити вперед, порівнюючи його безпосередньо з поверненням назад, а не в ізоляції — «ми виправляємо вперед» потребує обґрунтування, чому це швидше або безпечніше, ніж повернення назад, або це читається як припущення.
• Завжди записуйте ** обґрунтування рішення ** під час або відразу після інциденту, поки роздуми свіжі - реконструкція “чому ми вирішили це” через кілька днів під час постмортему є ненадійною і часто несправедливо критичною до розумного виклику в момент.
• Оголошення про рішення про відновлення з часовим штампом і ETA, а не просто «ми відновлюємо» - це дає команді конкретний сигнал про прогрес замість відкритої невизначеності під час активного інциденту.

Практичні вправи

1. Написати оголошення щодо гіпотетичного рішення щодо повернення, включаючи цільову версію і причину.
2. Поясніть різницю між перетягуванням назад і перетягуванням вперед, і коли кожен з цих варіантів є кращим.
3. Напишіть коротке обґрунтування рішення щодо відновлення, яке може з’ явитися у документі після смерті.

Навигація в розмові Rollback — фокус на точній мові

Будьмо чесними. Відновлення розгорнутої можливості рідко є * гарною * новиною. Це сигналізує про те, що щось пішло не так і часто викликає тривогу у всіх зацікавлених — розробників, тестерів, менеджерів продукту, навіть зацікавлених осіб, які очікували поліпшення. Способ, в который вы принимаете это решение, особенно когда объясняете его, абсолютно решающий. Це не про визнання провини (хоча визнання проблеми важливо), але про передачу ясності, відповідальності і шляху вперед. Неправильно сформулированное объяснение может усилить напряженность, замутить воду для будущих решений и повредить доверию.

Розглянемо деякі типові сценарії і як підійти до них з ретельно обраною фразою. Уявіть, що ви відповідаєте на коментар до вашого Запиту на завантаження — «Чому ми повернули це? Інтерфейс виглядає пошкодженим!» — негайно. Нерозумна реакція на кшталт “Це було неправильне рішення” не допоможе. Замість цього спробуйте щось на зразок: «Дякую за те, що ви висловили цю занепокоєність. Ми скасували розгортання через несподівану поведінку з [визначеним компонентом]. Ми виявили конфлікт під час тестування, який не був очевидним у нашому початковому середовищі. ” Зауважте використання « несподіваної поведінки » — це звучить більш професійно, ніж « це було пошкоджено ». Це змінює фокус від звинувачення до спостереження, і закладає основу для подальшого обговорення.

Інша ситуація може виникнути у каналі Slack: « Хтось знає, чому ми відновили роботу? » Поспішне, нечітке повідомлення на кшталт « Щось пішло не так » є недостатнім. Замість цього, створіть коротке повідомлення: «Ми відновили розгортання # 1234 через критичну регресію, що впливає на [захищену область]. Ми зараз розслідуємо кореневу причину і очікуємо оновлення до кінця дня. ” Це повідомляє про невідкладність і описує негайні дії, які будуть вжиті. Ключовим тут є визнання впливу - “критична регресія” - а не приниження його.

Нарешті, підготуючи пояснення для зацікавлених сторін, використовуйте мову, яка підкреслює навчання і вдосконалення. Уникайте технічного жаргону, де це можливо, і зосередьтеся на результатах. « Після відновлення розгортання # 1234, пов’ язаного з оновленням інтерфейсу користувача, ми виявили прогалини у нашому процесі тестування, що стосується інтеграції з [назва системи]. Ми впроваджуємо новий автоматизований набір тестів, спеціально присвячений цій області, разом з покращеним співробітництвом між розробкою і контролем якості, щоб запобігти подібним регресіям. “Це демонструє відповідальність, одночасно розглядаючи ситуацію як можливість для активних змін.