Самые смешные фейлы в IT-компаниях, которые никто не хочет признавать

В любой крупной IT-компании любят говорить о масштабах, надёжности и лучших практиках. Но если быть честными, за фасадом презентаций и отчётов почти всегда скрываются ситуации, которые одновременно хочется забыть и рассказывать новичкам как легенды. Мы собрали несколько фейлов, которые происходили, происходят и будут происходить в IT снова и снова, просто о них не принято говорить вслух.

Один из самых устойчивых жанров корпоративного IT - случайное действие в продакшене вместо тестовой среды.Удалённая таблица, перезаписанные данные, выключенный сервис - классика.

Формально причина почти всегда одна и та же:похожие окружения, усталость, привычка «я сто раз так делал».

Неформально - это результат культуры, где скорость долгое время важнее проверок, а человеческий фактор считается чем-то второстепенным.

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

Обновление зависимости, которое «ничего не должно сломать», — и внезапно падает половина системы.

Причина обычно банальна:скрытые зависимости, отсутствие тестов, незафиксированные версии.

Но в отчётах это часто выглядит как «непредсказуемое поведение стороннего компонента», хотя на самом деле — вполне предсказуемое последствие технического долга.

В больших компаниях документация почти всегда есть. Проблема в том, что ей не верят. Она устаревает быстрее, чем успевают закрываться тикеты, и в какой-то момент превращается в формальность, которую поддерживают «для галочки». В итоге новые сотрудники учатся не по документам, а по слухам, чатам и чужому коду.

Система падает, пользователи пишут в поддержку, менеджеры начинают задавать вопросы и только потом срабатывает алерт. Это смешно ровно до того момента, пока не начинаешь считать реальные потери времени и доверия. Причина почти всегда не в инструментах, а в том, что мониторинг настраивался «когда-нибудь потом».

Иногда кажется, что обсуждение сбоя занимает больше времени, чем сам сбой.

Созвоны, чаты, отчёты, презентации, и при этом минимальные изменения в процессах, чтобы ситуация не повторилась.

Это один из самых дорогих фейлов, потому что выглядит как работа, но не снижает риски.

Незаменимый сотрудник и гордость команды и одновременно её слабое место.

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

Потому что большинство из них про ошибки систем. Процессы, культура, приоритеты и компромиссы со временем накапливаются и проявляются именно так. Ирония в том, что почти все эти ситуации хорошо известны рынку, описаны в best practices и разобраны на конференциях, но продолжают происходить даже в самых зрелых компаниях.

IT-фейлы становятся по-настоящему опасными не тогда, когда случаются, а тогда, когда их перестают признавать.

Компании растут не за счёт отсутствия ошибок, а за счёт умения делать из них системные выводы, даже если сначала над этим хочется просто посмеяться.