«Устойчивость цифровой системы определяется не только технологиями»

Краснодарский край сегодня является одним из самых «цифровых» российских регионов. По официальным данным, за последние пять лет количество IT-компаний в регионе увеличилось почти в 3,5 раза. Банки, маркетплейсы, промышленные предприятия, транспортные компании — сегодня практически любой бизнес зависит от цифровой инфраструктуры. Сбои в работе даже одной информационной системы могут привести к финансовым потерям. При этом есть риск, о котором вспоминают только после первой серьезной «аварии»: критически важные знания о системе оказываются сосредоточены у одного человека (Key Person Risk). Пока этот специалист находится на связи, проблема остается незаметной. Но стоит ему уйти в отпуск, заболеть или сменить работу — компания сталкивается с форс-мажором. Почему такая ситуация возникает даже в сильных технологических командах и как ее избежать, рассказывает инженер-разработчик, специалист по работе с серверными системами и внедрению ИИ Данил Редько.

Выйти из полноэкранного режима

Развернуть на весь экран

— Данил, почему ситуация, когда только один человек понимает, как устроена система, вообще возникает? Разве современные компании не должны защищать себя от таких рисков?

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

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

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

— Насколько серьезно выросла система за это время?

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

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

— Был ли момент, когда вы особенно остро почувствовали, насколько опасна зависимость системы от одного человека?

— Да, такой случай хорошо запомнился. Поздним вечером перестала работать система автоматического сбора данных. Команда увидела только одно — информация перестала поступать. Началось вполне понятное беспокойство: никто не понимал, произошел сбой внутри нашей системы или проблема возникла у внешнего поставщика облачной инфраструктуры. Хотя в тот день я не дежурил, коллеги связались именно со мной.

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

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

— Многие специалисты воспринимают статус «незаменимого» как профессиональное признание. Почему вы считаете иначе?

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

— Как удалось снизить эту зависимость?

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

— Сегодня многие компании активно внедряют искусственный интеллект в разработку программного обеспечения. Может ли он решить подобную проблему?

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

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

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

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

— Какой главный вывод вы сделали за годы работы с такими проектами?

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

Беседовал Сергей Емельянов