Человек и машина

#машины_разное #люди

Прочитал пост у Димы про то, как автор любит обсуждать follow up’ы. Я же на той баррикаде, где обсуждать надо не обновления ранбуков и тестов, но архитектурные и организационные решения, которые повлияли на этот инцидент.

Немножко деталей: за последние 3 года я провел 44 разбора инцидентов, презентовал лично 5, 2 из которых запустили масштабную программу. Надеюсь когда-нибудь рассказать об этом опыте.

Автор поддерживаемого мною поста захотел отнестись к инцидентам, как к анти-дизайн ревью. Такой способ помогает командам и индивидам узнать больше о структуре и взаимодействии систем и команд, и о последствиях принятых решений. После такого разбора полетов, команда с набором свежих знаний может пересмотреть свои решения пока не стало слишком поздно для них самих.

Здесь кроется краеугольный камень: если мы обсуждаем обстоятельства, повлекшие к произошедшему инциденту, мы психологически ставим людей, принимавших решения тогда, в неудобное положение. Это наименее предпочтительно, чем ставить в неудобное положение презентующих инцидент, настаивая на важности тестирования, и мол будь у них интеграционный тест, инцидент был бы предотвращен.

Почему менее предпочтительно? Потому такие обсуждения бросают тень на работу этих самых принимающих решения. Впрочем, blameless он на то и blameless.

А вот что касается этих вот follow up’ов, то 99.999% инцидентов могут быть предотвращены:
- тестами;
- метриками и алертами;
- выплатой техдолга;
- ранбуками и тренингами.

Учитывая, что разбор полетов занимает минимум 30-40 минут, не вижу смысла собираться в комнате и обсуждать мониторинг и TDD. Взять к примеру из текста: «Do we think people should be following that runbook without a clear understanding of what each step means?»

Что этот вопрос предлагает? Что человек, проснувшийся в 4 утра от писка мониторинга, и задача которого быстро вернуть систему в рабочее состояние, должен «зачелленджить» ранбук? Если ранбуку нельзя доверять это плохой ранбук, и уж тем более не стоит взваливать на дежурного инженера дополнительный груз ответственности и когнитивной нагрузки поверх инцидента. Протокол есть протокол, и тут нечего обсуждать.

P.S. Прочитав пост и посмотрев профиль автора, который является CPO конторы, продающей инструмент для управления инцидентами, его мотивация становится понятной. Функциональность надо продавать!

www.tgoop.com/manandthemachine/831

1.1K viewsOct 28 at 08:50

#машины_разное #люди

Прочитал пост у Димы про то, как автор любит обсуждать follow up’ы. Я же на той баррикаде, где обсуждать надо не обновления ранбуков и тестов, но архитектурные и организационные решения, которые повлияли на этот инцидент.

Немножко деталей: за последние 3 года я провел 44 разбора инцидентов, презентовал лично 5, 2 из которых запустили масштабную программу. Надеюсь когда-нибудь рассказать об этом опыте.

Автор поддерживаемого мною поста захотел отнестись к инцидентам, как к анти-дизайн ревью. Такой способ помогает командам и индивидам узнать больше о структуре и взаимодействии систем и команд, и о последствиях принятых решений. После такого разбора полетов, команда с набором свежих знаний может пересмотреть свои решения пока не стало слишком поздно для них самих.

Здесь кроется краеугольный камень: если мы обсуждаем обстоятельства, повлекшие к произошедшему инциденту, мы психологически ставим людей, принимавших решения тогда, в неудобное положение. Это наименее предпочтительно, чем ставить в неудобное положение презентующих инцидент, настаивая на важности тестирования, и мол будь у них интеграционный тест, инцидент был бы предотвращен.

Почему менее предпочтительно? Потому такие обсуждения бросают тень на работу этих самых принимающих решения. Впрочем, blameless он на то и blameless.

А вот что касается этих вот follow up’ов, то 99.999% инцидентов могут быть предотвращены:
- тестами;
- метриками и алертами;
- выплатой техдолга;
- ранбуками и тренингами.

Учитывая, что разбор полетов занимает минимум 30-40 минут, не вижу смысла собираться в комнате и обсуждать мониторинг и TDD. Взять к примеру из текста: «Do we think people should be following that runbook without a clear understanding of what each step means?»

Что этот вопрос предлагает? Что человек, проснувшийся в 4 утра от писка мониторинга, и задача которого быстро вернуть систему в рабочее состояние, должен «зачелленджить» ранбук? Если ранбуку нельзя доверять это плохой ранбук, и уж тем более не стоит взваливать на дежурного инженера дополнительный груз ответственности и когнитивной нагрузки поверх инцидента. Протокол есть протокол, и тут нечего обсуждать.

P.S. Прочитав пост и посмотрев профиль автора, который является CPO конторы, продающей инструмент для управления инцидентами, его мотивация становится понятной. Функциональность надо продавать!

BY Человек и машина