Собирать осколки после катастрофы — проверенный способ учиться и совершенствоваться.
Пост-инцидентная проверка является жизненно важной частью процесса почти каждой команды разработчиков программного обеспечения.
После инцидента, из-за которого часть программного обеспечения перестала работать, мы входим и выясняем, что пошло не так. Как сделать так, чтобы в будущем было меньше шансов сломаться? Как мы можем восстановиться быстрее в следующий раз, когда что-то подобное произойдет?
Смысл процесса в том, чтобы учиться и совершенствоваться. Но проведение хорошей проверки после инцидента требует умения и здравого смысла. Вот пять советов, которые помогут вам усовершенствовать свою игру PIR.
1. Не торопитесь
Проверка после инцидента не просто так называется «после-инцидента». Во время инцидента восстановление нормального обслуживания должно быть единственным приоритетом. Сосредоточьтесь на том, что можно сделать здесь и сейчас, чтобы система снова заработала.
Вопросы и размышления о том, как можно было бы избежать проблемы, скорее всего, являются лишь отвлечением внимания, которое рискует отсрочить исправление.
Не только это, но и напряженность, вероятно, будет высокой, поскольку люди работают в условиях цейтнота, чтобы разрешить инцидент. В таких условиях будет сложнее оставаться объективным и не указывать пальцем. Это может быть клише, но культура отсутствия вины действительно важна. Сотрудники, которые чувствуют себя защищенными от обвинений, чаще высказываются, когда видят возможности для повышения безопасности.
Начинайте думать о пересмотре после инцидента только после того, как система снова заработает и инцидент будет устранен.
2. Знайте, что вы ищете
Вы видели Салли? Это отличный фильм, но ужасный пример рецензии после инцидента. Причина, по которой это плохо — и нереально, — в том, что следователи сосредотачиваются на неправильных вещах.
В реальном авиационном расследовании основное внимание уделяется безопасности. Никто не говорит о страховых выплатах и не допрашивает людей в качестве свидетелей. Вместо этого единственная цель состоит в том, чтобы определить возможности для улучшения систем и процессов.
Пост-инцидентные обзоры в разработке программного обеспечения должны быть такими же. Жизнь движется только вперед, и вы ищете способы повысить безопасность и сократить время отклика в будущем. Постройте обзор вокруг этих целей — не позволяйте ему превратиться в «что, если» или в обвинения.
Помните, что анализ принятия решений людьми не является целью. Люди несовершенны: это данность. Наши действия и решения ошибочны, и так будет всегда. Наша работа как инженеров заключается не в устранении человеческого фактора, а в разработке систем и процессов, в которых человеческие недостатки могут безопасно существовать. Когда что-то пойдет не так, всегда будут присутствовать человеческие ошибки, но нам нужно не обращать на них внимания и устранять системные сбои, которые позволили этим ошибкам стать проблемами.
3. Знайте свои пределы
Обзор после инцидента может охватывать много вопросов. Как бы много вы ни подготовили заранее, вы должны ожидать, что другие люди тоже поднимут то, о чем вы не подумали. К концу процесса у вас будет список заметок и предложений длиной с вашу руку.
Не поддавайтесь искушению просто записать их все в качестве пунктов действий и положить этому конец.
Причина проста: чем больше действий вы совершаете, тем меньше вероятность, что они будут выполнены. Разработка программного обеспечения движется в неумолимом темпе, и у вас уже больше задач, чем времени. Сколько раз вы видели, как корректирующие действия постепенно ускользают из нижней части списка дел?
Безжалостно сокращайте список действий. Удалите все, что кажется расплывчатым или трудно поддающимся измерению. Два твердых действия — хорошая цель, к которой нужно стремиться. Три — это слишком, а четыре — слишком много.
Даже одно очко действия — это хорошо. До тех пор, пока вы предпринимаете значимые шаги для повышения безопасности, проверка после инцидента служит своей цели.
4. Неудача неизбежна
Если вы не исправите каждую выявленную проблему, не оставите ли вы сознательно дверь открытой для новых проблем?
Каждая часть программного обеспечения может быть улучшена десятками способов — от тактического технического долга, который необходимо погасить, до слабой обработки ошибок, которую необходимо усилить. В большинстве случаев вы никак не сможете исправить все это.
Но, может быть, это нормально.
Пост-инцидентные обзоры в такой же степени направлены на подготовку к следующему инциденту, как и на предотвращение его. Потому что будет следующий инцидент. Даже если вы постоянно совершенствуете свои методы и системы безопасности, на самом деле вы позволяете себе строить больше, быстрее и лучше. И чем больше, быстрее и качественнее вы строите, тем сложнее становится система и тем больше вещей может пойти не так.
Не относитесь к инцидентам как к неудачам, а после инцидента — как к наказанию за них. Программное обеспечение движется быстро, и инциденты и восстановления, вероятно, всегда будут частью этого движения вперед. Единственный способ сделать код полностью безопасным — закрыть его и вернуться домой!
5. Общайтесь!
Когда вы проводите проверку после инцидента, пригласите к участию как можно больше людей. Сохранение процесса открытым и инклюзивным создает прекрасную культуру, которая сама по себе во многом способствует повышению безопасности. И если вы пишете отчет, распространяйте его как можно шире. Каждый отдел компании может извлечь пользу из извлеченных уроков.
Но не оставляйте его там.
Будьте мухой на стене и ходите на встречи других людей после инцидента! Вы не обязаны вносить свой вклад — на самом деле, вам лучше промолчать, если обсуждаемая система не является той, которую вы хорошо знаете, — но вы все равно можете кое-чему научиться.
Наблюдение за тем, что пошло не так с системами других людей, поможет вам быть готовым к тому, что ваше собственное программное обеспечение выйдет из строя. А наблюдение за корректирующими действиями, предпринятыми другими командами, может помочь вам внедрить процесс, который предотвратит сбои в будущем.
Но, возможно, самое главное, посещение других обзоров после инцидента поможет вам улучшить свою собственную игру PIR!
