Продолжая просмотр сайта и(или) нажимая , я соглашаюсь с использованием файлов cookie владельцем сайта в соответствии с Политикой в отношении файлов cookie в том числе на передачу данных, указанных в Политике, третьим лицам (статистическим службам сети Интернет), в соответствии с Пользовательским соглашением

Выберите страну или регион

Теорема о цифровой трансформации

26 января 2022

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

Предложим для формулировки своеобразную «теорему»:

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

Попробуем её доказать.

Как работают старые добрые legacy системы? Если не рассматривать совсем древние вещи типа мейнфреймов, то типичная легаси система на предприятии представляла собой толстый клиент – приложение для Windows, которое взаимодействует с центральным сервером базы данных. Фактически работоспособность этого сервера СУБД определяла работоспособность всей системы. Для него покупали по возможности сервер от известного производителя с максимально возможной надежностью. Зачастую серьезный отказ аппаратного обеспечения приводил к остановке на несколько дней (а то и недель - на время поставки запасных частей). В такой конструкции отказ системы недопустим, для его предотвращения проводятся профилактические мероприятия с полным отключением системы в нерабочие часы. Но в современном бизнесе уже не осталось понятия «нерабочие часы», бизнес стал непрерывным. Допустимый простой стал измеряться минутами, а зачастую секундами. К сожалению, решить эту задачу простым наращиванием мощности и «крутости» сервера и прочего железа не получится. Система, критически зависящая от одного компонента, ненадежна, что называется, «by design». Придется менять архитектуру целиком. В новой архитектуре возможность отказа системы в любой точке нужно принять за данность и заранее проектировать реакцию системы на такое событие. Таким образом рассмотрели отказоустойчивость системы.

Но в современных быстро меняющихся условиях важно еще и быстро реагировать на эти изменения. Типичная legacy система представляет собой так называемый «монолит» - цельный программный продукт, все части которого неразрывно связаны друг с другом. Чтобы выпустить новую версию – нужно согласованно изменить все её части. В наше время это занимает недопустимо много времени и потому в практику все больше и больше внедряется так называемый микросервисный подход, при котором отдельные функцинальные блоки разрабатываются и запускаются по отдельности. Это требует иного подхода к проектированию, но позволяет быстрее добавлять нужные функции и меньше зависеть от сбоев в отдельных частях системы. Очевидно, что при таком подходе единый продукт превращается в набор отдельных продуктов меньшего размера, плюс требуются специальные сервисы для обеспечения функционирования всего этого окружения. Резко увеличивается сложность запуска и эксплуатации. Для управления этой сложностью сам процесс запуска/обновления одного из частей программного продукта должен делаться полностью автоматически.

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

То, что описано в предыдущем абзаце и называют «архитектурой для облака» (или Cloud-Native architecture). И в данном случае не важно, публичное облако применяется или частное. Важен сам подход, который закладывает реакцию на сбои на архитектурном уровне, с использованием максимально унифицированных подходов к процессу разработки и эксплуатации. Только так можно снизить сложность современной ИТ системы, а значит снизить и риски для бизнеса.


Вверх