Одна ошибка при подключении VoIP-телефона оставила без интернета всю сеть клиники, а разбор инцидента занял около полутора часов после конца рабочего дня. Для российской IT-аудитории это не байка из серии «бывает», а очень узнаваемый кейс про слабый онбординг, дешёвую экономию на обучении и инфраструктуру, которая падает не из-за сложной атаки, а из-за одного неверно воткнутого кабеля.
Историю April, начинающего техспециалиста в компании с несколькими медицинскими клиниками, пересказывает The Register. На старте карьеры у неё был свежий сертификат CompTIA A+ и лишь косвенный опыт поддержки врачей, которые мучились с одним приложением. Этого хватило, чтобы получить работу с типичным набором задач «всё понемногу»: разворачивать новые ПК, возить их по площадкам, подключать рабочие места и закрывать сопутствующие мелочи. В какой-то момент ей поручили подготовить в клинике новое офисное пространство: девушка загрузила в машину несколько компьютеров, дюжину IP-телефонов и поехала на объект, дорога заняла 45 минут.
Сначала всё выглядело нормально. На каждом столе уже были выведены по два сетевых порта: один под телефон, второй под компьютер. Для начинающего сотрудника это почти подарок судьбы: меньше шансов перепутать схему, меньше поводов задавать неудобные вопросы. Сложность началась на тех местах, где нужно было подключить по два ПК. В такой конфигурации требовалось использовать второй Ethernet-порт на телефоне, чтобы один из компьютеров выходил в сеть через него. April закончила подключение даже раньше срока и уже рассчитывала спокойно дожить оставшиеся 15 минут до 17:00, когда к ней подошла медсестра с новостью: ни один компьютер во всей клинике не может выйти в интернет. Так локальная задача по оборудованию пары столов внезапно превратилась в аварию уровня «лежит вся сеть клиники».
Дальше началась классика полевого IT. Сотрудница, которой формально не доверяли задачи, способные «что-то реально сломать», первым делом решила, что проблема внешняя: порезали оптику, упал провайдер, случилось ещё что-то крупное и не зависящее от неё. Проверка быстро показала, что пинги не идут, а значит, сидеть и надеяться на чудо бессмысленно. Она позвонила в головной офис, надеясь, что коллеги ещё не разошлись, и следующие примерно час с лишним металась по площадке, выполняя команды старших по телефону, пока на место не прибыл специалист, который действительно понимал, как устроена сеть. Диагноз оказался почти обидным по простоте: в одном из IP-телефонов были подключены оба Ethernet-порта одновременно в сетевую инфраструктуру. Достаточно было вытащить один кабель, и всё заработало почти мгновенно.
В этой истории любопытна не только сама ошибка, но и реакция команды. Вместо истерики и показательной порки более опытный коллега просто похлопал новичка по плечу и сказал по сути одну вещь: второй раз ты так уже не сделаешь. Для культуры эксплуатации это важнее, чем может показаться. Ошибки джунов редко появляются из воздуха. Обычно это смесь из трёх факторов: человеку дали задачу чуть выше его реального уровня, не обеспечили нормальную инструкцию, а инфраструктуру собрали так, что единичное неверное действие превращается в общий сбой. Если после этого компания ещё и наказывает сотрудника за предсказуемый результат своей же управленческой экономии, она получает не дисциплину, а людей, которые боятся трогать продакшен, скрывают промахи и до последнего молчат об инцидентах.
Есть и ещё один штрих, который хорошо считывается именно в корпоративной среде. April сама убрала из табеля полтора часа переработки и зафиксировала окончание смены ровно в 17:00, решив, что не заслужила оплату за время, потраченное на исправление собственной ошибки. С человеческой точки зрения жест понятный; с точки зрения менеджмента и процессов — тревожный. Компания получила бесплатное устранение инцидента, возникшего в том числе из-за недостаточного обучения, а сотрудник закрепил у себя вредную логику: если ошибся, дорабатывай молча и за свой счёт. Для бизнеса это плохой сигнал. Такая культура создаёт кривую статистику, потому что реальные трудозатраты на инциденты не попадают ни в таймшиты, ни в отчёты, ни в планы по обучению. А дальше руководитель искренне удивляется, почему у него «вроде всё работает», но команда выгорает, а ввод в должность новых людей каждый раз напоминает лотерею.
Отдельно показательно, что после этой истории сотрудница сама, за собственные деньги, пошла получать сетевую сертификацию и несколько лет спустя стала одной из тех, кто уже «хотя бы примерно понимает, что делает». С одной стороны, финал почти оптимистичный: ошибка стала точкой роста. С другой — это довольно жёсткий комментарий к качеству найма и адаптации. Когда компания отправляет на площадку человека с базовым сертификатом, минимальным опытом и задачей, где нужно разбираться в коммутации, VoIP и поведении сетевого оборудования, она экономит здесь и сейчас, но берёт на себя риск уронить сеть клиники из-за действия, которое опытный инженер, возможно, даже не стал бы документировать как отдельный инцидент. В медицинской среде это особенно чувствительно: падение доступа в интернет для регистратуры, кабинетов и административных сотрудников быстро превращается не только в техническую проблему, но и в операционный сбой для всей организации.
Для разработчиков, системных администраторов, техлидов и IT-директоров мораль здесь неприятно приземлённая. Не каждая авария требует редкого бага, zero-day или дорогого железа с экзотическим firmware. Иногда достаточно непроговорённой схемы подключения, одного джуна без наставника и инфраструктуры, где ошибка на одном рабочем месте бьёт по всей площадке. Чем сильнее компании давят на скорость ввода людей и чем охотнее бросают новичков «разбираться на месте», тем чаще история про сеть клиники будет повторяться уже не в колонках западных изданий, а во внутренних чатах с пометкой «срочно, всё лежит».