TGViewer
Happy Devops — сообщество адекватных инженеров Happy Devops — сообщество адекватных инженеров @happy_devops · 1.8K subscribers
Post #318 1.22K
Про культуру без обвинений

В SRE-практиках есть одна, которую наиболее часто обходят стороной в России в силу запредельной токсичности наших команд. Не знаю, в силу менталитета ли или из-за доминирующего чувства собственной важности, но у нас ответ на извечный русский вопрос сильно сдвигает локус контроля в сторону "кто виноват?". А надо бы сдвигать к "что делать?"

Итак, культура без обвинений или blameless culture. В чем профит? Когда происходит какой-то инцидент любого вида, неважно, от упавшего прода до сломанной CI-ки, от критикал до лоу прайорити, то мы зачастую повинуемся древнему инстинкту и ищем виноватого. Чтобы закидать его камнями, оштрафовать, заставить переделывать, словом как-то попытаться научить его не делать больше так на негативном подкреплении, наглядно иллюстрируя про "если коллектив плюнет в тебя, то ты утонешь". Может быть это следствие совковой школьной системы образования, которой не нужны неудачники и любой отстающий становится объектом насмешек и унизительной процедуры "подтягивания по математике". И на этом строится в головах подростков фундамент модели взаимодействия с миром

Культура без обвинений, напротив, не ищет виноватых, а основой своей предполагает, что если что-то пошло не так, то потому, что мы об этом не подумали заранее и допустили такую возможность. Что-то не так в наших процессах. И команда собирается расследовать инцидент не для того, чтобы найти виноватого и отхуесосить его, чтобы надолго запомнил, а для того, чтобы написать постмортем, разобрать его и понять, где дырка в процессах, как так получилось, что чьи-то действия привели к тому, чему привели. И совместными усилиями найти эту дырку, поставить правильные задачи на ее закрытие и отписаться в постмортеме, какие действия были предприняты

Я встречал практику постмортемов (как и blameless culture), почему-то, только у прям больших ребят типа Озона или Яндекса. Почему-то маленькие команды не уделяют этому внимания от слова совсем. И потом вырастают программисты, у которых девопсы — это вахтеры, которые любой ценой стремятся саботировать процесс, и девопсы, у которых программисты настолько тупые, что не могут даже развернуть простейший пайплайн, что уж там говорить про установку кафки или сетапа БД в режиме master-passive. А рядом еще стоят продакты и просто недоумевают, почему те и другие настолько тугие и почему просто нельзя сразу писать без багов?

Ребятки, успешные команды работают вместе на результат, а не выясняют у кого полномочий больше.
More from @happy_devops
  1. Nov 28, 2025⚡ Совместный карьерный митап от Звук и self, сообщества для поддержки айтишников. Как стро…
  2. May 29, 2025🔥 База знаний тимлида: как въехать в процессы быстро и безболезненно! Подкаст Виктор Коре…
  3. Apr 16, 2025Дорогие друзья, уже на следующей неделе, 23 апреля в Амфитеатре Санкт-Петербургского конгр…
  4. Mar 28, 2025Eventual Consistency: когда доступность важнее мгновенной согласованности Eventual consist…
  5. Mar 26, 2025Гонка за новым функционалом не должна превращать систему в «хрупкого гиганта». SRE-практик…
  6. Mar 19, 2025Strong Consistency: между производительностью и надежностью данных Strong consistency — кл…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →