Чек-лист для руководства компании — на что обратить внимание перед новогодними праздниками

На носу длинные новогодние праздники — время забыть о работе и перезагрузиться. Но перед тем как уйти на отдых, стоит подумать о рисках, связанных с отказоустойчивостью ИТ-систем. Чтобы в выходные дни не пришлось в срочном порядке поднимать сервисы и отвлекать коллег.

Михаил Соловьев, директор по продуктам #CloudMTS , рассказал РБК, как подготовиться к новому году ИТ-директору. Специально для VC мы расширили тему и добавили удобный чек-лист, который поможет ИТ-директору и другим топ-менеджерам, желающим подготовиться к длинным выходным.

Каждый ИТ-директор «жонглирует» десятками информационных ресурсов. И чем старше его компания, тем их больше. Это — разного рода legacy, старая и новая почта, бухгалтерия, корпоративные порталы и системы управления предприятием и так далее. Например, специалисты из Sapient Insights Group утверждают, что каждая крупная организация (где больше тысячи сотрудников) в среднем использует шестнадцать различных решений только для HR (для сравнения, в 2019 году эта цифра была в два раза меньше).

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

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

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

Поставщики. Почти 70% руководителей позволяют сотрудникам и департаментам самостоятельно закупать лицензии. По статистике все той же компании Productiv, доля сервисов, которые работники применяют без прямого указания руководства, составляет более 56%. Этот тренд особенно заметен в контексте удаленки и несет в себе определенные риски — более половины дистанционных работников используют сторонние приложения (например, частные облачные хранилища) и загружают в них корпоративные данные.

Вариантом решения проблемы могут стать системы класса CASB — Cloud Access Security Broker. Они контролируют доступ пользователей к внешним облачным сервисам на основе внутренних политик. Однако ведение даже примитивного реестра поставщиков поможет разобраться не только с вопросами информационной безопасности, но и позволит иметь под рукой нужные контакты на случай, если потребуется синхронизировать обмен информацией или автоматизировать какие-то процессы — запросить документацию или обратиться за консультацией к вендорам.

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

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

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

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

В общем случае приложения можно разбить на четыре класса.

1. Особо важные системы (mission critical)

Допустимый срок восстановления — несколько минут.

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

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

Для защиты и обеспечения работоспособности особо важных систем полезны сервисы сетевой балансировки на основе DNS-протокола (GSLB). Они управляют трафиком между удаленными площадками, автоматически распределяя нагрузку на дата-центры.

Если в одном из них происходит сбой, клиентские запросы перенаправляются на резервное облако или ЦОД. Такую технологию предлагаем мы в #CloudMTS. Развернуть сервис могут не только наши клиенты, но и компании с инфраструктурой в облаке других провайдеров.

2. Бизнес-критические системы (business critical)

Допустимый срок восстановления — не более двух часов.

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

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

3. Обычные бизнес-приложения (business operational)

Допустимый срок восстановления — от четырех до шести часов.

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

4. Некритичные приложения (office productivity)

Допустимый срок восстановления — несколько дней.

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

Когда список критически важных сервисов составлен, необходимо проверить и утвердить план Disaster Recovery. Он нужен, чтобы восстановить данные и инфраструктуру при взломе, ошибке сотрудника или проблемах с железом. К сожалению, ни один бизнес не застрахован от случайной потери данных — она может произойти даже из-за сбоя в прошивке СХД. Чем критичнее для бизнеса приложение или сервис, тем раньше должно быть начато аварийное восстановление его работы.

Для особо важных и бизнес-критических сервисов, где недопустим длительный простой, необходима резервная инфраструктура – в случае ЧП она примет на себя весь пользовательский трафик. Эту инфраструктуру может предоставить облако в рамках Disaster Recovery.

В общем случае возможны два сценария.

Первый — корпоративные сервисы запущены on-premise, а в качестве резерва выступает облако.

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

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

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