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