Обратная сторона ИТ: люди, железо, сеть, код, проекты, эксплуатация, безопасность

Вернулся к докладу ноября 2021 года на V Международной научно-практической конференции. Тогда я был директором по информационным технологиям Берг Холдинг. Конференция уже «смешанная»: часть в зале, часть в Zoom. Мне пришлось конкурировать с обедом. Не самая удачная позиция для докладчика: зал вполне мог выбрать столовую. Поэтому я был краток. Нужна была карта, вид с высоты птичьего полёта.

Видео: выступление на YouTube. Ниже конспект того доклада и то, как я смотрю на те же семь зон в 2026 году.

Для бизнеса ИТ обычно представляется как сопровождение или какие-то дополнительные возможности развития. Удобство, рост, новые сервисы. Это всё верно и замечательно. Безусловно, «правильное ИТ» даёт новые возможности и позволяет повысить конкурентоспособность. Но давайте посмотрим на ИТ и с другой стороны. А что, если система остановилась, сможете ли вы работать дальше? Или сразу включается стоп-кран на выручку, и пока не будет поднята критическая инфраструктура, вы фактически прекращаете свою деятельность? Если не учитывать риски, связанные с обеспечением непрерывности бизнеса со стороны ИТ, через какое-то время обнаруживается нехорошая ситуация. Критическая система оказывается очень хрупкой, её поддержка почему-то стала выливаться в кругленькую сумму, и знает, как работает система, всего один «незаменимый» специалист, или вообще никто не знает.

Перед моим выступлением Арсен Благов из Ростелекома говорил про IT с человеческим лицом: сервис, забота, поддержка. Это всё замечательно. Но я намеренно взял альтернативную сторону. Бизнесу полезно понимать, что происходит «под капотом» ИТ. Я постарался подсветить, образно выражаясь, «обратную сторону луны». Чтобы у бизнеса была целостная картина. Иначе они получают ИТ с сюрпризом. И сюрприз этот не из приятных.

Прежде всего, IT – это не просто служба, которая меняет картриджи. За первой линией стоит сложный комплекс: люди, железо, сеть, код, проекты, эксплуатация и безопасность. И каждая из описанных зон может влиять на выручку как положительно, так и отрицательно. Ниже семь зон, которые я тогда выделил. Актуальность и приоритизация рисков с того времени несколько изменились.

Персонал

Как ни странно, я поставил её первой. Потом из зала спросили, какая наибольшая уязвимость российского IT-сектора. Ответ тот же. Люди.

Пандемия резко подняла спрос. Особенно не хватало профессионалов высокого уровня. Часть компаний этот момент проспала и потеряла команду. Рынок перегрелся. Рос фонд оплаты труда. Вместе с ним росли стоимость проектов и стоимость владения системами.

На новые задачи стало труднее найти профессионалов. Сбер, Яндекс, Ozon «пылесосили рынок» и забирали лучших кандидатов. Удалёнка для IT стала нормой. Компании, которые не успели перестроиться и говорили: «нет, сидите строго в офисе с девяти до шести», потеряли свои команды и не были способны нанять новых людей.

Есть известная фраза: «незаменимых людей нет». Но на практике сплочённая и мотивированная команда, которая знает свою инфраструктуру и платформы, работает значительно эффективнее того коллектива, где текучка персонала более 10 % в месяц и полная неразбериха с передачей знаний. Если команда сплочённая, но есть один-два человека, которые тянут на себе «всё», возникает вопрос. Что будет, если единственный человек, который компетентен и даже очень лоялен компании, вдруг «попадёт под автобус»? На первый план выходят такие понятия, как автобусный тест (bus factor) или риск ключевого сотрудника (Key Person Risk).

Серверы

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

При этом зачастую оказывается, что на имеющееся оборудование гарантии нет, запчастей нет, мощность под потолком, и запаса для масштабирования нет. Про непрерывность бизнеса никто не думает. Резерва нет: сервер умер, заменить нечем. Плана, что делать, если сервер уничтожен, тоже нет.

А что, если сервер «лёг» и система перестала работать? Бизнес в этот момент останавливается или начинает тормозить так, что бурный поток выручки превращается в тонкий ручеёк или вовсе пересыхает.

Этот риск надо учитывать до того, как произойдёт остановка.

Сеть

Сеть однозначно относится в текущих реалиях к критической инфраструктуре. Удалёнка держится на сети. Если сеть собрана на домашних коммутаторах, без нормального администрирования и мониторинга, компания не успевает масштабироваться. Горячего резерва зачастую нет. Если один роутер или коммутатор вышел из строя, второй должен обеспечить непрерывную работу так, чтобы никто и не заметил поломки. На оборудовании «домашнего» уровня обеспечить бесперебойность, как правило, невозможно. Сбои идут чаще и бьют сразу по всем системам.

Можно представить, что серверы – это мозг. Перегруженный мозг думает плохо. Сеть – это нервная система. По ней идут сигналы. Если нервная система собрана из того, что было под рукой, мозг может быть сколько угодно мощным, но вся система целиком работать не будет.

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

Разработка

Как правило, проблемы в разработке созревают незаметно и постепенно. Причина часто проста – проблема роста.

Что это такое, болезнь роста? Пока компания маленькая, есть один программист. Ему сказали «напиши». Он написал. Потом ещё. Потом ещё. Всё пишется «на коленке». Документации нет, архитектуры нет. В результате получившийся код стыдно показать постороннему человеку. Преемственности в передаче знаний нет, и даже если нанимается уже несколько человек, ситуация становится ещё более запутанной. Это риск.

Многие говорят: мол, мы работаем по Agile. Следует знать, что гибкие методы здесь часто путают с работой без правил. Agile же на самом деле дисциплины не отменяет. Работа, которую сделала одна команда, должна быть «продолжаема» другой. Иначе код на коленке под модным словом Agile становится зоной риска. Это тоже риск.

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

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

Кульминацией всех вышеперечисленных рисков является «Спаситель», уникальный специалист. Уникальный потому, что помнит весь ворох стеков, костылей, нюансов. На рынке такого же специалиста с таким же набором скиллов нет. Бизнес подсаживается на зависимость от одного «незаменимого». И это опять риск, который относится к блоку персонала, который я описал ранее. В спокойные годы этот риск не так заметен, хотя и отрицательно влияет на развитие. В неспокойные времена это уже точка отказа.

Проекты

В PMBoK управление рисками – это отдельный большой раздел. В данном случае я затрагиваю проектные риски вскользь.

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

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

Ещё один риск: нет предпроектного исследования. Как правило, все эти риски «ходят» строем.

Вместо того чтобы понять, а что, собственно, надо, сразу ищут поставщика и бегут в «светлое будущее». Куда бежим, зачем бежим, нужно ли вообще в эту сторону двигаться? Никто не спросил. Через год смотрят вокруг и не понимают, зачем всё это делали. А усилий, времени и денег потратили уже массу.

Ещё один риск: отсутствие проектной документации. Сделали что-то уникальное. Зачем, почему, как устроено, что получили: ничего не записано. Передать в эксплуатацию нельзя. Остаётся поделка и диктат того, кто её (поделку) собирал.

А почему обычно возникают вышеизложенные риски? Ответ простой: нет проектной культуры. Методология может быть любой, Waterfall или Agile. Важно, чтобы внутри умели вести проекты, ну, как проекты. Иначе наряду с описанными проектными рисками у заказчика (бизнес-подразделения) заводится некий «карманный» программист, и вы снова в зоне «разработки на коленке».

Эксплуатация

Самая дорогая иллюзия: закончили проект, шарики, фейерверки, раздача медалей, счастье наступило, система далее будет жить сама по себе. А не будет! Система требует эксплуатации!

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

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

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

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

Информационная безопасность

С этого блока обычно начинают любой разговор про IT-риски. Я же его оставил на закуску. Риски здесь известные. Не буду перечислять их все. Времени мало. Рассмотрю самый обширный.

Сотрудникам нужен доступ к ресурсам, в том числе извне. Периметр при этом должен быть закрыт от вторжения. Нужны антивирус, резервное и архивное копирование. Компании придётся выработать политику: всё запретить наглухо или разрешать, но под присмотром. Отслеживать, кто куда ходит и зачем, разбирать нарушения. Для бизнес-критичных систем снова те же два требования. Резерв и план восстановления. Если у вас внешний периметр открыт и бесконтролен, это большой системный риск.

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

Риски, связанные с обеспечением требований законодательства, я тогда, в 2021 году, глубоко не рассматривал. Хотя в текущих реалиях они очень важны, и соответствие этим требованиям «стоит очень много денег».

P.S. В 2022 году количество угроз и нагрузка на кибербезопасность возросли кратно. Но это будет тема «докторской диссертации».

Обратная сторона луны

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

Все семь зон рисков я рассматривал в 2021 году через призму обеспечения непрерывности бизнеса (Business Continuity).

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

Нужно принять как аксиому: серверы, сети, информационные системы на этом железе будут ломаться. Вопрос не в том, сломается ли. И даже не в том, когда сломаются. Вопрос в том, продолжит ли ваш бизнес работать после сбоя? Будет ли поступать выручка? Хватит ли производительности для масштабирования? Знаете ли вы, что делать, когда произойдёт внештатная ситуация?

Для оценки, в упрощённом виде, удобно использовать три оси. Они взяты из методологии TODOIT: System Exposure.

Первая ось: хрупкость. Насколько систему легко сломать. Один сервер, один программист, один поставщик. Ударил в точку, всё рассыпалось. Плохо, слабо.

Вторая ось: устойчивость. Насколько система держит удар и как быстро восстанавливается. Сервер может быть один, зато есть RAID и копия, из которой можно быстро восстановиться. Получается, что хрупкость высокая: сломать легко, но и восстановить быстро и недорого тоже можно.

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

В полной методологии также есть ось антихрупкости.

Оценка по данным осям позволит вам оценить подверженность вашего бизнеса тем или иным рискам и принять соответствующие управленческие решения.

Можно, конечно, сказать, что именно с нами ничего подобного не случится. Авось пронесёт. Но, наверное, стоит обратить внимание на примеры из реальной жизни, которые были тогда приведены.

Два примера с той сессии.

Первый рассказал Арсен Благов. Март 2020 года, нужно перевести людей на удалёнку. Речь шла о порядке 130 тысяч человек в Ростелекоме и дочерних обществах. Компания была к этому технологически готова. За одну-две недели перевели всех, кто должен был уйти из офиса. Если бы готовности не было, встал бы сам бизнес. Это и есть работающая реакция на кризис.

Второй из моей практики. Лет за десять до доклада аудитор из Coca-Cola спросил, глядя на красивую серверную: а что будет, если сюда сейчас упадёт самолёт. Я ответил честно. Серверной конец и бизнесу тоже. Тогда этот вопрос звучал дико. Сейчас, в 2026 году, этот вопрос вызывает желание задуматься поглубже. Этот сценарий мы тогда не просчитывали и ничего под него не делали. В аудите появилось замечание про катастрофоустойчивость, которое следовало устранить. Оборудование разнесли по площадкам. Обеспечили переключение всей работы в течение 2 часов на резервный ЦОД. После этого компания уже держала удар другого класса.

Самолёт в серверную – это, конечно, крайность для того времени. Тут же вопрос звучит буднично. Что будет, если уволится единственный человек, который знает систему? Или если поставщик ERP или иной критической системы завтра поднимет цену вдвое.

Авось пронесёт?

Эта статья и сама классификация ничего не внедряют. Они нужны для другого – убрать слепое пятно. Перед следующим IT-проектом или перед разговором про «давайте цифровизируемся» достаточно пройтись по семи зонам, возможно, стоит пройти быстрый check-up по TODOIT: System Exposure и спросить по каждой: где у нас есть точки отказа, и что произойдёт с бизнесом, если риск реализуется.

Если ответа нет, риск уже есть. Просто он ещё не выставил счёт.