Czytaj książkę: «В заложниках у ИТ»

Глава

Об авторе

Давайте знакомиться, я — Александр Афанасьев — эксперт в повышении эффективности ИТ-функции для малого и среднего бизнеса. Многократно выстраивал эффективную работу ИТ-департамента с ИТ-бюджетом до миллиарда рублей и количеством ИТ-специалистов до 200 человек. Также специализируюсь на импортозамещении, разработке собственных ИТ-продуктов, высоконагруженных систем и сервисов.

Помимо этого, я практикующий ИТ-директор с опытом работы в отрасли более 20 лет, за моими плечами:

более 50 ИТ-диагностик, завершившихся комплексной стратегией развития ИТ-функции;

более 30 проведенных ИТ-трансформаций, завершившихся влиянием на бизнес-эффект;

разработка с нуля и внедрение высоконагруженных систем на миллионы пользователей;

многократное внедрение таких коробочных ИТ-продуктов, как ERP, WMS, TMS, OMS, DWH, BI, MDM, CRM, ESB, PLM, ЭДО, сайтов, мобильных приложений и других решений для бизнеса;

владение практиками Agile и Waterfall и умение подобрать эффективные методы работы для конкретных компаний и ИТ-продуктов;

управление ИТ-коллективами до 350 чел

Я выпустил большое количество статей, веду собственный Telegram-канал, в котором простым языком рассказываю о подводных камнях и проблемах в ИТ и способах их разрешения. В моих мероприятиях принимают участие лидеры бизнеса разных стран. Я являюсь финалистом конкурса управленцев «Лидеры России 2023-2024», лидером рейтинга «Топ-100 CIO» (Москва, 2023 год), спикером и экспертом бизнес-конференций UPGRADE, OBOROT, членом жюри премии «Большой Оборот 2023, 2024» и экспертом в ИТ-менеджменте, как опытный управленец в области цифровизации бизнеса по версии изданий «РИА НОВОСТИ», CNEWS, TAdviser.

Среди моих клиентов владельцы и руководители малого и среднего бизнеса, а также топ-менеджеры крупных федеральных и международных компаний. Проекты по реализации флагманских услуг моей компании «ИТ Диагностика», «Interim CIO», «ИТ-отдел по подписке» охватывают всю территорию России и стран СНГ.

Введение

Цифровая эпоха подобна обоюдоострому мечу, способному преображать мир и угрожать его существованию. В реалиях информационных технологий все буквально на расстоянии клика мыши: от удобства и эффективности до слежки и кибератак. С каждым новым днем сфера ИТ становится все более интригующей и сложной, требуя от нас постоянного обучения, адаптации и, конечно же, бдительности.

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

Здесь я расскажу о существовании такого парадоксального явления, как манипулирование собственником бизнеса со стороны команды ИТ-специалистов. Само по себе явление манипуляции информацией не ново и может быть проявлено в любом бизнесе и направлении, например, в бухгалтерии. Но ИТ-сфера отличается тем, что для выявления манипуляции со стороны своих сотрудников недостаточно задать правильные вопросы.

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

Далее я приведу описание проблематики, раскрою первопричины и дам пошаговый алгоритм предотвращения проблем с ИТ-специалистами.

Современный бизнес, особенно средний и крупный, невозможно представить без ИТ-составляющей. Всегда есть сайт, приложение, система кассовых аппаратов или электронный документооборот. Клиентам отправляются уведомления об акциях, а онлайн-оплата проходит через настроенный эквайринг. Многозадачность руководителя бизнеса приводит к тому, что он так или иначе перестает полностью контролировать все отделы. Зачастую бизнесмен даже не подозревает, что он в заложниках. А когда начинает понимать, боится изменить ситуацию, так как думает, что любые изменения в ИТ приведут к краху бизнеса. Быть в заложниках — значит не иметь возможности изменить ситуацию к лучшему, но в этой книге я покажу, что выход есть всегда.

Дисклеймер

Некоторые имена, детали и названия компаний изменены. Любое совпадение с реальными людьми и событиями — случайно.

Глава 1

1.1. Могло быть и хуже: история ООО «Кастрюлька» и Гвидона Панина

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

К моему приходу сотрудники службы информационной безопасности отчаялись в попытках заставить эту команду не быть единоличными владельцами всей инфраструктуры и все-таки поделиться паролями, доступами и документацией. Вы спросите: почему компания так от них зависела и не могла этих сотрудников уволить? Ответ прост: держа все пароли у себя, по сути, они держали за горло всю компанию. Это и был их козырь, та самая иголка в яйце. Компания, в прямом смысле, была в заложниках, как и любая другая тоже будет, если попадет в такие обстоятельства.

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

Представьте ситуацию, пришел какой-то новый дядька в сплоченный десятилетием совместной работы коллектив и раздает какие-то новые непривычные указания. Да, он ИТ-директор, а они его подчиненные, но у них-то в руках ключи от всех замков. Обратную связь мне давали в духе — «Ты сегодня ИТ-директор, а завтра на твое место придет другой, а мы тут были и будем всегда, никто нас никогда не уволит». Это и была одна из причин, по которым я пришел к выводу — любые мои попытки перестроить коллег в конструктивное русло будут безуспешными, я понял, что нужны кардинальные методы решения проблемы. Было принято решение уволить главаря этой банды Гвидона Панина. Но тут-то в этой истории и началось все самое интересное…

1.2. Новая эра в отделе. От проблем к возможностям

Когда я только пришёл в ООО «Кастрюлька», работа показалась мне понятной, привычной и предсказуемой. Без проблем, требующих срочного решения, и резких прорывов в светлое будущее. Ещё на собеседовании генеральный директор объяснил задачи, стоящие передо мной:

поступательное развитие ИТ-функции;

повышение уровня автоматизации бизнеса;

решение проблемы сроков и бюджетов изменений;

оптимизация коммуникации между подразделениями;

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

С первых дней я начал погружаться в бизнес-процессы компании и изучать имеющиеся проблемы. Первым шагом стал тщательный аудит — как внутренний, так и внешний — с целью анализа процессов, коммуникации и взаимодействия между подразделениями. Это было необходимо для создания полноценной картины текущего состояния ИТ-инфраструктуры и выявления проблемных областей. Результаты внешнего и внутреннего аудита не заставили себя долго ждать и оказались весьма показательными.

Основными проблемами были:

недостаточная связь между ИТ-подразделениями — области ответственности были размыты настолько, что задачи часто «блуждали» от одного отдела к другому без четкого ответственного;

отсутствие синергии между программным обеспечением и инфраструктурой — разработчики и системные администраторы плохо взаимодействовали между собой, что приводило к задержкам в оказании ИТ-сервиса;

размытая ролевая модель — функциональные роли были распределены между разными членами одной команды, в результате чего было непонятно, кто в целом отвечает за тот или иной сервис или блок работ, что приводило к пробелам в реализации функции, как следствие, к ошибкам и проблемам в информационных системах;

недостаток компетенций частично компенсировался активным участием членов команды, но этого было недостаточно для оказания ИТ-сервиса требуемого качества;

отсутствие сквозных ИТ-процессов не позволяло построить эффективный конвейер создания и поставки результата;

отсутствие процессов работы с заказчиками не позволяло корректно управлять приоритетами;

отсутствие правил коммуникации приводило к взаимным обвинениям между ИТ-отделом и представителями бизнеса в срывах сроков и низком качестве интегрального ИТ-продукта.

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

Понимая основные проблемы, я разработал план действий:

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

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

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

Внедрение числовых показателей эффективности работы, чтобы получить объективную оценку качества рабочих процессов и результата.

Перераспределение рабочих обязанностей, группировка компетенций и закрепление ответственности за ту или иную зону на конкретное подразделение в лице его руководителя.

Несмотря на положительные изменения в ИТ-департаменте в целом, проблемы с Гвидоном оставались актуальными и парадоксально усугублялись. Его отказ брать на себя ответственность за задачи системного администрирования продолжал препятствовать нашему общему прогрессу. На контакт Гвидон не шел, все поручения выполнял показательно формально, предложений не вносил, все предложения окружающих коллег оспаривал, не приводя сильных аргументов, регулярно требовал четкого ТЗ и регламентов, стараясь бюрократизировать рабочий процесс до степени его саботажа. Я осознавал, что без решения этого вопроса все наши усилия по улучшению коммуникации внутри ИТ-департамента могут оказаться напрасными. Так оно, в принципе, и случилось. Отсутствие инициативы и прозрачности в деятельности одного отдела в итоге поставило всю компанию под угрозу коллапса.

1.3. Развитие событий: первые признаки и что будет, если их не заметить вовремя

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

Принимая решение расстаться с Паниным, честно говоря, я предполагал, что самым сложным будет объяснить человеку, проработавшему 10 лет в компании, что он перестал соответствовать ее задачам. Я заранее нашёл ему замену, вызвал Гвидона к себе, «по-взрослому» объяснил, что низкая эффективность его деятельности и отсутствие результата по поставленным задачам вредят развитию компании, и предложил написать заявление на увольнение по собственному желанию. Мы договорились об определенной, причем немаленькой сумме в размере трех месячных окладов, так сказать, отпускных и разошлись на хорошей ноте, пожав друг другу руки. Мне показалось, что дальше никаких проблем не будет, и мы сразу перейдем к построению новой качественной ИТ-инфраструктуры. Как же я в тот момент ошибался!

Подозревая, что Панин захочет как-то накрутить свою команду, посеять в ней сомнения о перспективности дальнейшей работы в компании, я заранее подготовился к различным вариантам развития событий и провел переговоры с несколькими подрядчиками, договорившись о возможности их оперативного подключения для передачи дел. Но этот вариант виделся мне даже не планом Б, а скорее В или даже Г, хотя очень хотелось провести все по плану А, мирно и без конфликтов.

Однако одной из нерешаемых проблем было нежелание Гвидона допускать моего прямого общения со своей командой. Он всегда был буфером между нами. У меня не было возможности задать вопрос напрямую, например, сетевому инженеру, Гвидон был против такого подхода. Поэтому мои слова и указания передавались команде с искажениями, а мнение команды передавалось мне в выгодном для него свете.

Этим Гвидон и воспользовался. После разговора со мной он пришёл к своим подчинённым, с которыми проработал около 10 лет, и рассказал, что я уволил его незаслуженно и без объяснений, после чего предложил своим сотрудникам поддержать его делом. В тот же день, в течение двух часов после этой встречи, трое сотрудников его отдела прибежали в офис компании и одновременно написали заявления на увольнение по собственному желанию. Коллеги прекрасно понимали, что все пароли, ключи, доступы от критической инфраструктуры компании по-прежнему только у них в руках. Они чувствовали себя незаменимыми, и их целью было отменить принятое решение об увольнении Гвидона Панина.

Не скажу, что ранее я такого не ожидал, наоборот, я подозревал, что именно так коллеги и поступят, но рассчитывал, что у нас будет достаточно времени на обмен информацией и передачу дел. Думал, что у нас впереди будет хотя бы пара месяцев, пока обидевшиеся за увольнение друга сотрудники втайне ищут новую работу. Я провел переговоры с каждым из коллег и со всеми сразу, но результата это не принесло, поскольку я был для них чужим, а словам Гвидона они верили. Каждый из них заявил, что больше положенных двух недель дорабатывать не собирается. От последующего сотрудничества в формате ГПХ или СЗ с оплатой по человеко-часам или фиксированной суммой в месяц коллеги также наотрез отказались. Однако они не учли, что, во-первых, генеральный директор был изначально осведомлён о происходящем и согласен с принятым мною решением об увольнении зачинщика, а во-вторых, политика нашего руководства была такая — с шантажистами и «террористами» переговоров не ведём, даже если мы плотно у них на крючке. Поэтому все заявления на увольнение по собственному желанию были сразу же подписаны. С этого момента начался отсчет времени на изъятие недокументированной ИТ-инфраструктуры, на которой работает весь бизнес, у немотивированной на передачу дел команды, владеющей всеми ключами от этой инфраструктуры и способной ее выключить за несколько секунд.

Честно говоря, в тот момент я думал, что самым сложным будет в краткий срок перенять понимание инфраструктуры, знания о ее устройстве, с учетом того, что уходящие коллеги честно расскажут, как она устроена и ответят на возникающие вопросы. После чего нам оставалось бы забрать все пароли и восстановить документацию, которую они за 10 лет работы особо и не накопили, держа всё в своих светлых головах. Ребятам за неделю до ухода были выплачены все их заработанные деньги, премии, поэтому я предполагал, что они просто все расскажут, отдадут пароли и уйдут. Но реальность оказалась гораздо интереснее.

Документацию нам получить не удалось. Рассказать об устройстве ИТ-ландшафта и его архитектуре коллеги также отказались. Пароли они передали, но не от всех сервисов и серверов, специально утаив важнейшие ключи от неочевидных ИТ-сервисов, которые без получения доступов и в условиях жесточайшего цейтнота было практически невозможно быстро найти или восстановить. На конкретно задаваемые вопросы отвечали выборочно и не в полном объеме. По сути, все эти две недели у нас продолжалась игра в хозяев положения и заложников, в которой экстренно привлеченная по договору подряда команда системных администраторов пыталась быстро раскопать особенности нашей инфраструктуры в условиях информационного вакуума. Что это было — тонкий расчёт или простая детская обида, сложно сказать, да и не так важно.

Иллюстрация 1. Как это всё устроено?

На видео с камер наблюдения в ЦОД было видно, как Гвидон физически отключал провода от серверов и уносил их в неизвестном направлении, а на протяжении последующих месяцев я регулярно сталкивался с последствиями злонамеренного удаления ИТ-сервисов со стороны его команды. Таким образом, они целенаправленно уничтожили около 60% ИТ-сервисов и практически все технические данные, такие как бэкапы, системы мониторинга и централизованного управления ИТ-сервисами.

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

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

Особенность ИТ-инфраструктуры состоит в том, что если ты не знаешь точно её объёмы и архитектурное устройство, то исследование — дело непростое, трудозатратное, требует наличия разнообразных компетенций и времени, даже если у тебя есть все пароли. Но у нас не было всех паролей, и это значительно усложняло ситуацию. Хорошо, что, надеясь на лучшее, но готовясь к худшему, я заранее подготовил резервные планы действий и провел переговоры с внешними командами. Это позволило в кризисный момент не терять время и сразу же начать спасать компанию.

Иллюстрация 2. Объем бедствия. С чего начать?

Спасение началось со взлома собственного оборудования. Мы ночевали в центрах обработки данных (ЦОДах), подключались к нашему оборудованию, сбрасывали на нем пароли и настройки, перехватывали доступ администратора к собственным серверам, виртуальным машинам, СХД, коммутаторам и далее искали и исправляли все те уязвимости, которые нам оставили перед уходом бывшие сотрудники.

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

1.4.

Оценка действий: без эмоций и субъективности

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

Иллюстрация 3. Если ничего не делать

Первая проблема, которую удалось решить, это отсутствие доступа ко всей компьютерной сети. Благодаря тому, что мы получили доступ к сетевому оборудованию (коммутаторам, маршрутизаторам), стало понятно, как в компании устроено сетевое взаимодействие. Мы нашли устройства, админские пароли, от которых нам не отдавали, и восстановили пароли от этих устройств путем фактической перепрошивки. Помимо этого, в сети мы нашли подозрительные сетевые устройства, которые занимались перегонкой подозрительного трафика в неизвестном направлении. Их нам удалось отключить. Убедившись, что отключение этих устройств никак не повлияло на работу компании, мы полностью перепрошили их и задействовали под нужды компании. Далее необходимо было получить доступ ко всем серверам, которые обеспечивают работоспособность нашей компании, но для этого надо обладать паролями, а их у нас не было, причем как от гипервизора (система, позволяющая на одном физическом сервере создавать несколько виртуальных машин), что являлось очень серьезной проблемой, так и от самих виртуальных машин, работающих на этом гипервизоре. Восстановить пароли от виртуальных машин было нетрудно, это достаточно типовая операция для систем Windows и Linux, однако, пока ты не получишь доступ к самому гипервизору, восстановить пароль от операционной системы не получится.

В нашем случае использовался гипервизор ESXi, его производит компания VMware. Для решения стоявшей перед нами задачи я привлек экспертов, которые работают на рынке инфраструктуры достаточно давно и имеют огромный практический опыт работы с нашим оборудованием. Задача звучала так: «Нам необходимо восстановить доступы, пароли от гипервизоров, заново подключить систему хранения данных, которую ушедшие коллеги отключили специально и очистили, восстановить удаленные доступы ко всем остальным серверам, чтобы не обязательно было приезжать в ЦОД ночью для перезагрузки сервера, починить те серверы, которые «лежали» выключенными у нас в ЦОДе, так как предыдущая команда не очень желала чинить старые серверы и всегда предпочитала покупать новые».

Самым сложным оказалось восстановление паролей от гипервизора, поскольку это промышленный продукт, требующий прямого подключения проводом и защищенный от несанкционированного вмешательства. Чтобы решить задачу, мы провели переговоры с лучшими экспертами рынка и в итоге разработали четкий план восстановления. И хотя эксперты декларировали, что это очень непростая, сложная и опасная операция, мы пошли на этот шаг. Операция была опасной, потому что при неправильном восстановлении или неправильных действиях мы рисковали потерять все данные, которые хранятся в виртуальных машинах, управляемых гипервизором, то есть мы могли потерять абсолютно всю информацию, которую пытались, наоборот, восстановить. В одну из множества ночей, посвященных восстановлению ИТ-инфраструктуры, мы приехали в ЦОД, подключились к физическим серверам проводом и приступили к работе. Несмотря на то, что с первого раза результат достигнут не был, все-таки оборудование защищено от взлома, в конечном счете, задача была успешно решена. Если бы нам не удалось ее решить, работа компании была бы остановлена как минимум на несколько недель. А это означает практически стопроцентное закрытие бизнеса.

Также бывшие коллеги не отдали нам пароли от нашей ключевой системы хранения данных (СХД) Huawei DORADO. СХД — это такой большой и умный жесткий диск объемом более 100 терабайт, на котором хранятся все критичные данные компании. Восстановлением этих паролей тоже пришлось заниматься самим. Здесь мы точно так же воспользовались услугами экспертов из моего нетворкинга (все-таки не каждый день удается заниматься взломом собственного оборудования), съездив в ЦОД и подключившись непосредственно кабелем к системе хранения данных, эти пароли благополучно были восстановлены. Если бы нам это не удалось, все данные компании были бы утеряны, а компания остановила бы работу навсегда.

Далее мы взялись за множество виртуальных машин на Linux и Windows, от которых у нас не было пароля администратора, но в свете всех тех проблем и событий, которые мы уже решили, данная задача была из разряда рутины. Загвоздка, правда, была в том, что для восстановления пароля администратора требовалась перезагрузка сервера, а далеко не все виртуальные машины можно было легко остановить, поскольку часть из них были критичны для работы бизнеса. Но в конечном счете, этот вопрос тоже был решен путем согласования технологических окон с бизнесом. Тут стоит выразить благодарность бизнесу за адекватное понимание ситуации и содействие в восстановительных работах.

Какой же еще сюрприз нам преподнесли бывшие коллеги? У нас в компании используется специальная система для хранения паролей — так называемый Password Manager (Менеджер паролей). Этим менеджером должны пользоваться все сотрудники, чтобы пароли компании оставались внутри компании, а не хранились у кого-то в головах, в текстовых файликах или еще где-то. Но по факту пользовался этой системой кто угодно, кроме самих сисадминов, хотя их пароли там должны были быть в первую очередь. Уходя, они фактически уничтожили конфигурационный файл базы данных менеджера паролей, оставив ее в рабочем состоянии до момента перезагрузки сервера. Получалось следующее: если бы мы случайно или намеренно перезагрузили сервер, на котором работает наша система хранения паролей, мы бы навсегда потеряли все наши пароли, которые там хранились. Это, к сожалению, выяснилось не сразу, но хорошо, что мы его не перезагружали, а электричество в ЦОД работало без сбоев. В конечном счете мы решили проблему. Поскольку Password Manager нельзя было перезагружать, мы сняли с него резервную копию, пока он работал, создали и запустили новый пустой сервер менеджера паролей, в который загрузили пароли из резервной копии.

У нас была еще одна очень важная система — TMG (Microsoft Forefront Threat Management Gateway), через которую проходил весь внешний трафик компании. Поломку этой системы нам тоже любезно подготовили. Уходящая команда вместо четырех рабочих серверов оставила два, причем наименее мощных. То есть уничтожила два самых мощных сервера, оставив всю систему на морально устаревших «костылях». Также был уничтожен пульт управления правилами маршрутизации трафика, что не позволяло нам теперь делать необходимые настройки в TMG. Мы как будто оказались на самолете, летящем на скорости 900 км/ч на высоте 10 000 метров без штурвала и с одним двигателем. И этот самолет летит, пока у него есть горючее, но скоро оно закончится, и наш самолет превратится в тыкву, падающую вниз с огромной скоростью. Горючее должно было закончиться 9 апреля (помню ту дату как сейчас), потому что у нас заканчивался срок действия Wildcard-сертификата, и нам требовалось заменить его заранее купленным новым сертификатом. Сделать это без паролей и без управляющего сервера было невозможно. Поэтому до 9 апреля (а это примерно меньше месяца от момента, когда мы это поняли) наша компания должна была либо исправить эту проблему, либо остановить свою работу навсегда. Ключевая проблема, собственно, была в том, что вместе с ведущим сервером был уничтожен файл конфигурации, в котором записано достаточно большое количество правил маршрутизации трафика, описывающих внутренности нашей компании. Восстановить с нуля новый сервер без этих правил — работа на несколько часов. Однако без этого файла конфигурации запустить в реальную работу новую систему не получится, а создать новый файл означает несколько недель простоя компании. К тому же TMG не поддерживается производителем аж с 2012 года, то есть на момент написания этой книги система не поддерживается более десяти лет. И по ней не осталось сильных специалистов, все уже давно перешли на более современные системы.