Тема дня: как наказывать разработчика?
Предпосылкой поста стал недавний случай удаления яндексом части виртуальных машин в облаке.
Причиной этого стала человеческая ошибка. Не на том сервере скрипт запустили, ошиблись командой..в общем не день бэкхема был у разработчика, который нажал "Enter".
И ситуаций таких не так мало, вот тоже известные случаи:
[Junior, который в первый день работы удалил базу данных с production](https://habr.com/ru/company/flant/blog/330750/)
Gitlab «лежит», база уничтожена (восстанавливается)
Многие задают вопрос, а как правильно наказывать сотрудников, факап же все-таки не маленький.
А у меня возникает вопрос, почему в принципе люди задают такой вопрос? Они не понимают, что на месте каждого из "счастливчиков" мог бы оказаться он сам? Когда у нас в стране что-то бабахает, вы рады, когда сажают или наказывают очередного операциониста, а менять законы, требования к пожарной безопасности, менять саму работу органов - нафиг? Ну усилили проверки на следующие 3 месяца, а толку-то..
То, что произошло - всего лишь симптом, наказание бедного сотрудника, никаким образом не поможет предотвратить подобную причину в будущем. При подобных происшествиях надо проводить Root cause analysis, в котором уже давным давно всё описано: надо понять что случилось, почему случилось. Определить, что можно сделать для того, чтобы предотвратить повторное возникновение проблемы.
Можно использовать знаменитую технику "5 whys", которым руководствовался Сакичи Тоёта на тоёте. После второго why будет очевидно, что наказание сотрудника не поможет. Скорее всего дело как всегда в процессе.
Например, неплохо тестировать бэкапы на восстановление. И это не рокет сайенс, в любой методологии ИТ процессов об этом пишут (ITIL, COBIT и т д).
Вот если уже конкретные люди противятся изменениям, не понимая рисков и причин этих изменений - это уже другой вопрос.
Post #22
408