Comments 15
Объявили "амнистию" — никаких наказаний за инциденты
А когда я говорю, что рукожопы по факту не несут ответственности, мне говорят, чтоя выдумываю.
Ну и да.
Современный подход "Contributing Factors":
contributing_factors:
immediate:
Конфигурационный файл содержал опечатку
Валидация конфига отсутствовала
environmental:
Деплой выполнялся в пятницу вечером
Основной эксперт был в отпуске
systemic:
Процесс деплоя не требовал peer review
Отсутствовала документация по конфигурации
Staging окружение не идентично production
organizational:
Давление на скорость релизов
Недостаток времени на техдолг
У каждого из этих пунктов есть имя и должность.
А то что Вы пишете, называется "размывание ответственности", и это не "современный подход", а очень старый способ сделать вид, что "оно само так произошло".
ты в целом прав — размывание ответственности реально существует, и когда «никто не виноват», всё обычно заканчивается тем, что никто и ничего не меняет. Это бесит, согласен.
Но сам подход “blameless” по идее не про то, чтобы отмазать рукожопов. Он про то, чтобы разобрать, почему система вообще допустила ошибку, а не просто повесить всех собак на одного человека. Потому что если кто-то нажал не ту кнопку — значит, у нас есть процесс, где это можно было сделать без проверки, без подтверждения, без safeguards.
Наказание конкретного человека проблему не решает, оно максимум даёт ощущение справедливости. А вот если после инцидента команда спокойно разбирает, что пошло не так, и назначает конкретные действия и ответственных за исправление — тогда уже появляется смысл.
Так что да, ответственность должна быть. Просто не “кто виноват”, а “кто теперь делает, чтобы не повторилось”. А если этим прикрываются и ничего не чинят — ну, тогда это уже не “blameless”, а просто безответственность под модным словом.
Но сам подход “blameless” по идее не про то, чтобы отмазать рукожопов.
Он на то, чтобы освободить от страха сознательных исполнителей, которые стараются делать хорошо, но находятся под гнётом наказания.
Но для этого надо, чтобы человек сперва вырос в условиях жёсткого контроля и умел и хотел контролировать себя сам. А у нас вся отрасль выросла в условиях "никто не виноват, потому что тут всё очень сложно и слишком много людей участвует".
Потому что если кто-то нажал не ту кнопку — значит, у нас есть процесс, где это можно было сделать без проверки, без подтверждения, без safeguards.
И этот процесс кто-то утвердил. Он будет наказан?
процесс утвердил конкретный человек, и он тоже несёт ответственность. Просто не в формате «наказать», а в формате «разобраться и исправить, чтобы больше не повторилось».
Ну вот об этом и речь - отрасль живёт в атмофсере полной безнаказанности, поэтому нет никаких причин делать что-то хорошо. Если из-за твоего рукожопства куча людей и компаний получат проблемы и убытки, то лично тебе ПОФИГ!
Хороший подход мне кажется. А размывание ответственности можно обойти ещё одним уровнем, на котором эти шаги привязываются к определенному человеку (до того, как что то произошло, а не после) Это позволяет создать гибкие обязанности на основе фактической роли человека в проекте, а не на том, что должен человек делать на формально занимаемой должности.
а когда каждый этап будет закреплен за определенным человеком занимающим формально определенную должность, сформируется и методология, с определенным набором качеств под определенную роль
Я очень призываю использовать опыт отраслей, где правила написаны кровью - например ICAO. Является совершенно обязательным отделить техническое расследование от административного. Техническое расследование - делается именно так, как описано в статье: обезличенно, опираясь на факты - с целью выработать мероприятия для предотвращения (или хотя бы смягчения последствий). На этом уровне очень важно понимать, что любые мероприятия до определенного момента снижают частоту инцидентов "фронтально", но в какой-то момент вы упираетесь в предел: можно снижать вероятность одних только за счет других (вы не можете одновременно требовать от пилотов и вылетать по расписанию в любую погоду, и не заходить на посадку при плохой видимости - чудес не бывает!). И дальше - обязанность бизнеса сказать чем он готов рисковать, а чем - нет.
А помимо технического расследования (но возможно, с учетом его материалов) - можно проводить административное расследование, чтобы установить выполнили ли участники событий свои обязанности. В рамках административного расследования, однако, следует возрерживаться от объективного вменения - раз наступили неблагоприятные последствия, значит виновен. Следует ограничиться выяснением обстоятельств указывающих на вину в виде умысла (желал наступления неблагоприятных последствий), или преступной небрежности (не желал наступления, предвидел и допускал возникновение, однако надеялся что последствия не наступят).
Административные же последствия должны наступать в ситуации, когда предписанный порядок действий существовал, был достаточен для предотвращения негативных последствий, но не исполнялся. Например - чеклист предусматривал прогнать конфиг через lint, но это не было сделано (а галочка - поставлена, или не сделано и не поставлено - и деплоили с невыполненным чеклистом). Или дежурный не поставив никого в известность - был вне зоны доступа в течение часа с возникновения проблемы...
Разумеется, здесь есть риск начать писать инструкции в стиле "техники безопасности для канатоходца": при движении по канату совершайте плавные и размеренные движения, удерживая проекцию центра тяжести тела в пределах площади опоры. "Кто упал, тот нарушил!" (C) Контрольный вопрос для предотвращения: правила и инструкции должны быть такими, чтобы вы могли с легким сердцем наказать за неисполнение ДАЖЕ если в конкретном случае ничего страшного не произошло. Ибо если люди деплоят не выполняя чеклисты - им надо делать втык и объяснять, что с теорией вероятности играть не следует - эта тварь всегда выигрывает...
Опять же - необходимо предусматривать процедуру выхода за пределы инструкций, если они не применимы к ситуации. Иначе можно получить итальянскую забастовку (все сидят и ждут - но по-инструкции)! Крайне желательно чтобы отступления от инструкции (вместе с мотивами этого) и предполагаемые действия фиксировались средствами объективного контроля (запись в журнале, пост в канале тимз). Очень важно чтобы все (включая менеджмент) понимали что записывая отступление от инструкции, человек освобождается от ответственности (кроме случаев умысла на причинение вреда). Ибо административная процедура не может наказывать за ошибки - а только за виновные действия!
В конечном счете - для успеха необходимо совместить два действия: конвертировать ошибки в опыт - не вызывая паралича воли у исполнителей, и одновременно дискриминировать (вплоть до увольнения) - необучаемых мудаков...
Более забавны ситуации, когда на протяжении многих лет известны реальные индивиды, которые своими руками и мозгами принимают решения без опоры на реальность, строят планы и графики реализации проектов, сложных интеграций подсистем в единое поставляемое заказчикам решение. И всякий раз у них приключения на итоговой фазе сдачи проекта.
И всякий раз оказывается, что эти скоморохи забыли написать ТЗ для отдельного модуля, не продумали модель данных, элементарно не включили в план работы по тестированию решения под нагрузкой целевой и даже не имеют малейшего представления о том, какой она должна быть.
При получении нейтрального письма-постмортемы, эти ребята нежно розовеют и предпочитают опять игнорировать факты.
Они выбирают безопасный для себя путь - просто с текущей точки начать писать ТЗ, но очень лениво и неохотно.
Коллеги, которые должны проверить работу решения под нагрузкой не могут с многих десятков попыток достучаться и получить описание профиля целевого нагружения, описания критичных сценариев конкретной кастомной подсистемы.
Когда данные получены и выполняется первичная ручная проверка сценариев - оказывается отдельные подсистемы не работают и требуют доработки.
Когда в рабочую группу добавляют руководство - теневые размыватели ответственности начинают писать клеветнические письма, что группа коллег, которые в последние 2% времени по их плану должна провести нагрузочные испытания по их графику - отказывается работать.
На этом этапе они говорят, что коллеги срывают график, но игнорируют факты и отказываются признавать, что ТЗ и профиль нагружения ещё не описаны, сценариев нет.
Здесь же стимулируется эмоциональная неприязнь и нежелание читать письма с фактами и перечнем необходимых мер.
Реальный пример из финтеха: Джуниор инженер случайно удалил индекс в production базе. Боясь увольнения, он потратил 6 часов, пытаясь восстановить его втайне.
Что это за "финтех", если не секрет, в котором джун может лазать в админском режиме грязными руками в продовой базе? При чём "тайно".
Хотелось бы знать, чтобы случайно не воспользоваться "услугами" этой организации.
Postmortem без обвинений: Миф или реальность?