Зачастую для компаний, деятельность которых не связана напрямую с ИТ, камнем преткновения становится локальная серверная комната.
С одной стороны, для поддержания его жизнеспособности необходимы постоянные денежные вливания.
С другой стороны, не хватает опыта, чтобы справиться со всем накопившимся наследием.
Ниже мы поговорим о том, как несколько организационных упущений, текучесть кадров и экономия на оборудовании едва не стали причиной крупных проблем – и как облака и опыт проектная группа помог решить все быстро и без потерь.
Компания «Рушимсет», занимающаяся поставками химического сырья и материалов, была основана в 2000 году.
В настоящее время она имеет 15 офисов по всей стране, 4 зарубежных дочерних предприятия и 28 логистических центров.
Согласитесь, довольно большой список.
Географическое распространение – от Минска до Красноярска.
Без цифровизации никуда: инфраструктура компании должна работать как единый слаженный механизм, а внутренние сервисы должны быть доступны любому сотруднику в доли секунды.
Чтобы не было «моя программа зависла, ничего сделать нельзя».
Новая инфраструктура и новые проблемы
Исторически сложилось так, что клиент строил свою инфраструктуру на базе серверов Tower. В условиях роста потребностей бизнес-систем такой выбор повлек за собой ряд проблем: сложности с размещением (особенно в небольшой серверной комнате), проблемы с охлаждением, относительно низкую плотность приложений на один сервер.
Все это и ряд других проблем сильно тормозили развитие ИТ-систем заказчика.
Рушимсет также столкнулся с рядом неудачных архитектурных решений.
Например, vSAN. Сама технология отражает современные подходы к организации высокопроизводительного и отказоустойчивого хранилища SDS (Software Defined Storage).
Однако проблемы на сайте, слабая серверная база, отсутствие достаточного опыта и неразвитость сетевого стека привели к сбоям в работе хранилища и высоким рискам потери данных.
Все это привело к необходимости постоянно «латать дыры».
По словам администраторов клиентов, аварии иногда происходили каждый день в течение недели.
К 2015 году внутри компании было построено частное облако на базе решений VMware. Это позволило избавиться от фрагментации офисов (которые, кстати, работали по аналоговому соединению без серверов).
Однако через пару лет возникли новые неприятности.
В 2017 году в энергосистеме произошли две серьезные аварии: сеть упала, а общий простой составил более двух суток.
Диски стали дополнительным источником проблем.
В целях экономии использовалось самомонтируемое неавторизованное оборудование.
Из-за чрезмерной нагрузки на отдельные хосты возникал дефицит процессорного времени и оперативной памяти.
Также в 2017 году компания претерпела масштабное расширение, и существующей инфраструктуры стало недостаточно.
Нагрузка увеличилась на 40%.
Ситуацию осложняла частая смена ИТ-специалистов, что не позволяло обеспечить необходимый уровень поддержки местных ресурсов.
Переезд в облако
Здесь мы подходим к очень щекотливому моменту, который характерен для большинства клиентов, не специализирующихся на ИТ и желающих сэкономить.Менеджеры «Рушимсети» в первую очередь изучили предложения облачных провайдеров в графе «стоимость услуг».
Их можно понять: после травмирующего опыта с частным облаком хочется максимально снять с себя груз финансовой ответственности за ИТ-мощности.
Не будем лишний раз пугать вас историями о переподписке и дырах в безопасности у мелких провайдеров.
Важно понимать, для каких целей арендуется место в облаке: для размещения небольшого веб-приложения или серьезной бизнес-системы.
Руководство ИТ-отдела компании ранее имело положительный опыт работы с #CloudMTS. Летом 2018 года мы начали переговоры, обсуждая с клиентом необходимые ресурсы и объем миграционных работ.
Первая сложность, о которой мы уже говорили выше, — это частые кадровые изменения в ИТ-отделе компании.
Накопилось немало «технического долга».
Кто-то что-то делал, не успел закончить или задокументировать и уволился.
Пришел новый сотрудник, не успел разобраться в инфраструктуре, начал оптимизировать и тоже уволился.
Проблемы росли как снежный ком.
В какой-то момент нам пришлось взять взаимный тайм-аут и приостановить проект «до выяснения».
Изучение различных способов решения проблемы подтвердило, что переход в облако — лучший вариант с экономической и технической точки зрения:
- процесс масштабирования железа дорог и сложен, а облако даст возможность гибко управлять количеством ресурсов;
- миграция позволит переложить задачу обеспечения отказоустойчивости на плечи провайдера;
- Практически нет задач, которые нельзя перенести в публичное облако.
Подготовительный этап
Прежде чем предпринимать решительные действия, необходимо изучить инфраструктуру, провести тесты и определиться с пулом услуг, которые потребуются заказчику.Дело «Рухимсети» осложнялось тем, что любая задержка могла привести к остановке бизнеса.
Нам нужно было действовать как можно быстрее.
Процесс подготовки состоял из нескольких этапов.
1. Аудит инфраструктуры Прежде всего, мы изучили ИТ-ландшафт компании, чтобы понять состояние ее сервисов.
В результате был составлен список систем и их взаимодействий.
Разработан план миграции.
Здесь возникло несколько неприятных проблем, требовавших немедленного вмешательства и исправления.
Например, служба Active Directory работала неправильно.
Пришлось восстанавливать его и одновременно решать проблемы с сетевой связью.
2. Первичное планирование Раньше сомнений в необходимости миграции и устаревании оборудования не было.
Аудит лишь подтвердил гипотезу о том, что в сложившейся ситуации переезд является оптимальным методом решения проблем с учетом сроков и инвестиций.
Мы провели первоначальное планирование и наметили спектр сервисов, которые в конечном итоге будут перенесены на облачную платформу.
3. Оптимизация запросов В результате первоначального планирования у нас появилась новая информация.
Необходимо было четко решить, какие сервисы следует перенести в облако, а какие логичнее оставить на инфраструктуре заказчика.
Соответственно, на оптимизацию запросов и проработку оптимальных способов их решения было потрачено еще некоторое время.
4. Утверждение бюджета проекта Необходимо было договориться о стоимости новой инфраструктуры.
В среднем публичное облако оказалось в 2-3 раза экономичнее частного варианта.
5. Окончательный план миграции Наконец, мы подготовили комплексный план.
Миграция была разделена на два этапа.
В первую очередь в облако были перенесены системы 1С, затем все остальные компоненты инфраструктуры.
Миграция
Еще одна неприятная ловушка заключается в том, что инфраструктура клиента была чрезвычайно централизована.Данные с рабочих столов пользователей и почты были консолидированы на два файловых сервера емкостью 7 ТБ и 3 ТБ соответственно.
В первой итерации планирования время простоя от начала копирования данных до запуска сервисов на новой локации составило 4 дня.
Перед миграцией нам пришлось принять участие в привычном для клиента марафоне решения инфраструктурных катастроф.
Мы запросили доступ и с помощью наших специалистов из Профессиональных служб полностью стабилизировали ситуацию и провели все необходимые подготовительные работы для последующей миграции.
Жесткие сроки диктовали единственно возможный вариант — поднять максимально быстрый канал, тиражировать и переключать всё, что можно, с минимальными простоями.
Разработан и согласован план миграции; он включал подробный алгоритм миграции каждой системы и описывал волны миграции — от наиболее критичных систем к наименее критичным.
Также был составлен план проверки ИТ-систем в облаке и план оптимизации серверов через 1-2 недели после миграции.
Как мы писали выше, миграция проводилась в два этапа.
В общей сложности процесс длился с декабря 2018 года по начало июня 2019 года.
В самом конце АТС компании переехала в облако.
Некоторые системы, например, видеонаблюдение, не имело смысла переносить в облако, и их оставили локально.
Если описанный выше случай близок вашей компании, вы можете обратиться за консультацией к специалистам #CloudMTS. Традиционно ждём ваши истории и вопросы в комментариях.
Теги: #инфраструктура #ИТ-инфраструктура #облачные сервисы #облако #миграция в облако
-
Новые Функции Blogger Проходят Тестирование.
19 Dec, 24 -
Новые Вещи Не Решат Старых Проблем
19 Dec, 24 -
Что Нужно Знать Об Arc
19 Dec, 24
