Надежность VS инновации: как не потопить компанию, балансируя между стабильностью и внедрением нового

20 мая 2024 г.

Автоматизация, она же цифровизация, и сопутствующие ей нескончаемые обновления соответствующего ПО стали будничной реальностью для большинства компаний. И, с одной стороны, подобные нововведения действительно идут бизнес-процессам на пользу. Да и куда уже спрячешься от автоматизации, если она постепенно начинает внедряться как необходимость даже на уровне законодательства? А с другой стороны, мало кто задумывается о том, что в гонке за инновациями и бесконечными обновлениями уже внедренных программ можно потерять главное — сам бизнес. Как же найти священный грааль баланса между надежностью и инновациями, и нужно ли внедрять все обновления без исключения? Разбираемся вместе с DevOps-инженером Владимиром Фролкиным.

Последние 20 лет скорость разработки как процесса растет все больше и больше. Если в условном 2004 году обновление для Microsoft Word могло выходить раз в полгода или даже год, то сегодня увидеть уведомление о выходе свежего обновления можно чаще, чем раз в неделю. Новые инструменты вкупе с новыми методологиями позволяют отправлять только что измененный код от разработчика к клиенту в течение часа, а иногда и быстрее. То же самое мы можем сказать и о новом уровне доступности разработки и, впоследствии, увеличении количества решений и инструментов. Теперь на каждый предыдущий инструмент инженеры накидывают новый слой абстракции, чтобы сделать разработку проще, количество требуемых навыков меньше, а стоимость этой разработки ниже.

Что можно потерять в гонке за обновлениями

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

Аргумент против N1. Стабильность

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

Аргумент против N2. Затраты на обновление

Если в случае с Windows 10 пользователь нажал кнопку, и оно там само все поехало, то в промышленных системах так редко работает. Чаще наоборот: чтобы обновить какой-то инструмент, нужен подходящий специалист, а главное — его время, которое стоит денег. Повезет, если не будет никаких зависимостей, и обновление будет только нужного компонента. А ведь это не всегда так. Например, чтобы обновить PHP до 8.0, необходимо иметь OS Ubuntu только версии 20 и выше. А у нас может оказаться 18, которая нас вполне устраивала. То есть может сработать принцип домино. Вообще есть и такие системы, которые обновляются недели или даже месяцы. Например, сервисы Amazon или Google. На все это, очевидно, требуется много затрат.

Аргумент против N3. Приостановка рабочих процессов (даунтайм)

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

Зачем инновации все же нужны

В общем, очевидных причин достаточно, чтобы не встречать каждое обновление с восторгом. Лучшее — действительно враг хорошего. Но обновляться все же придется. И вот почему.

Аргумент за N1. Безопасность

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

Красноречивым будет пример американского бюро кредитных историй Equifax. В 2017 году произошел один из самых масштабных случаев утечки данных в истории — была взломана система Equifax. Хакеры украли личные данные 147 млн американцев и нескольких миллионов британцев и канадцев. Взлом был осуществлён из-за того, что инженеры вовремя не обновили веб-приложение Apache Struts. Уязвимость была известная, и патч уже был выпущен, но ИБ решили не торопиться. Компания потеряла 700 млн долл. и репутацию. Естественно, политики безопасности компания изменила.

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

Аргумент за N2. Производительность

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

Хорошим примером будет реальный кейс JPMorgan Chase. Несмотря на то, что это один из крупнейших банков мира, в марте 2021 года из-за отсутствия масштабируемости и гибкости инфраструктуры компании произошел сбой в работе платежной системы Zelle. Это привело к огромному количеству задержек и ошибок при проведении транзакций, что вызвало сильное недовольство среди пользователей и отразилось на репутации банка. По итогу уже в сентябре того же года компания объявила о переходе на облачные технологии для обеспечения масштабируемости. И к концу 2024 года планирует перевести 75% своих данных в AWS и GCP. Так как это компания мирового уровня, такой сбой не смог уничтожить бизнес, но банки поменьше могут потерять всё и закрыться.

Что можно сделать сейчас: перейти на облачные технологии, который помогают быстро масштабировать инфраструктуру, внедрить DevOps и CI/CD (если этого до сих пор нет в компании) и настроить анализ производительности (например, с помощью непрерывного мониторинга).

Аргумент за N3. Совместимость

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

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

Из недавних примеров можно вспомнить немецкую компанию Greefa, которая до сих пор использует операционную систему MS-DOS. В результате несвоевременной модернизации компания столкнулась с серьезными проблемами в найме сотрудников, которые могут работать с их инфраструктурой. MS-DOS вышла из употребления в начале 2000-х. Большая часть специалистов переквалифицировалось, а технологии сегодняшнего дня не поддерживают MS-DOS. По итогу всю инфраструктуру нужно создавать буквально с нуля и как-то переносить данные. Это создает большие проблемы, и в первую очередь финансовые — необходимо нанять специалистов, которые могут создать современную архитектуру, но имели также хотя бы минимальные знания о MS-DOS, и что-то сделать со старыми сотрудниками.

Что можно сделать сейчас: провести аудит всей инфраструктуры, чтобы вычислить, какие компоненты сильно устарели и требуют модернизации (своевременная модернизация поможет устранить слабые места с минимальными затратами), распланировать поэтапное обновление, инвестировать в обучение сотрудников.

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

Источник: Владимир Фролкин, DevOps-инженер