Шеннон Уэйрик, вице-президент по архитектуре DNS-провайдера NS1, поделился на портале InformationWeek опытом по осуществлению трансформационного проекта без перебоев в операциях компании.

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

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

Проектирование и создание нового «самолета»

С 2014 г. в компании происходил сверхинтенсивный платформенный рост. Хотя в архитектуру ее первичного DNS-сервера было заложено горизонтальное масштабирование, этот процесс исчерпал свои возможности. Компании требовалось обзавестись новыми функциями, несовместимыми со старой кодовой базой. Мерой успеха в переработке своего ПО компания поставила улучшение производительности (количество обрабатываемых запросов в секунду) по крайней мере в десять раз, обеспечение поддержки DNSSEC с цифровыми подписями, сохранение (на новой основе) всего ранее действовавшего набора специализированных функций, включая цепочки фильтров, используемых в управлении трафиком, и развертывание прямо на ходу сделанного в масштабе работающей платформы.

При реализации этого проекта были усвоены пять уроков.

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

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

Постепенный ввод нового функционала. В любом крупном проекте трансформации очень важно создать систему раннего предупреждения проблем посредством тестирования и подтверждения правильности результатов каждой стадии проекта. Компания использовала периферийную сеть с Anycast-пересылкой пакетов для отвода контролируемой доли трафика к точкам присутствия (PoP) и серверам, принадлежащим новой системе. При постепенном увеличении доли трафика, обслуживаемого новым стеком, пристально отслеживалась операционная надежность системы. В бюджет были заложены два-три месяца работы по тестированию, оценке и дальнейшей доработке решений. Управление трафиком, обрабатываемым новыми системами, позволило быстро идентифицировать проблемы.

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

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

Новый «самолет» в полете

Оценив проделанную работу, в NS1 убедились, что производительность обработки запросов выросла не, как планировалось, в 10, а в 20–40 раз. Операции стали стабильнее, так как система стала справляться с выбросами нагрузки в более малых PoP. Сократился средний уровень задержек, стали реже происходившие в некоторых регионах перебои и замедления работы. Компания смогла ввести в действие новый функционал, сохранив прежние специализированные функции. Самое главное, она справилась с проектом без всяких простоев, отказов или нарушений в обслуживании пользователей. В целом этот проект принес радикальные преимущества и клиентам, и самой компании, открыв простор для роста и инноваций на ближайшее десятилетие.

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

Версия для печати (без изображений)