Мы используем как аутсорс, так и свои внутренние ресурсы ИТ-отдела. На одном физическом сервере может быть сервис, за который отвечают внешние сотрудники и сервис, за который отвечаем мы. И от сезона эти сервисы могут мигрировать внутрь компании или выходить наружу.
Началась история с того, что нам понадобилась централизованная система с фермой терминалов. На тот момент у нас было порядка 10 магазинов, и каждый из них вёл свою базу, данные из которой использовались для составления совокупного отчёта в конце периода или по запросу.
Централизация
Описанная схема оказалась очень неудобной — нужно было всё время знать, где и что находится на складах, плюс выводить наличие товара в реальном времени на сайт. Соответственно, мы централизовали базу и сделали так, что магазины стали работать через терминальный доступ к ней. До этого мы так не хотели делать из-за требований к каналу связи.
Естественно, возникла проблема с отключением интернета: если канал слабел или падал (что случается практически всегда — вопрос времени), магазин оставался без кассы. То есть чеки пробивать ещё было можно (тогда использовалось разделение IT и физической кассы), но вот учёт летел ко всем чертям до исправления. Допускать такого было нельзя, поэтому мы решили пойти простым путём — резервированием каналов. Завели в каждый магазин по два физических кабеля от разных провайдеров, закупили «USB-свистков», но, в целом, ситуация от этого если и стала проще, то ненамного. Всё равно кто-нибудь падал рано или поздно.
Следующим шагом была распределённая база данных. Мастер-база хранится в дата-центре, а на каждом магазине есть своя версия базы (точнее, фрагмент, имеющий отношение именно к этому магазину). В случае отказа интернет-канала магазин продолжает работать в своей версии базы, а при появлении соединения происходит асинхронный апдейт основной базы. При наличии стабильного канала апдейты идут в реальном времени. Если канал падает — данные «добиваются» при восстановлении, просто магазин на некоторое время уходит из сети. Кстати, то же наличие товара считается уже на центральных инстансах по матожиданию — например, при скорости продаж 5 коробок игры в день, и наличии 8 коробок на складе магазина без связи, к обеду там будет не «В наличии», а «кончается, звоните». Цель — не накосячить так, что человек приехал, а игры нет.
Железо
Железо менялось всё это время. Первый сервер был в довольно дешёвом ЦОДе, но оттуда мы очень быстро ушли, поскольку работать было невозможно. Дальше пошли по пути «всё домой» и попробовали развернуть сервер в офисе, откуда, собственно, делалась репликация баз магазинов. Проблема та же — когда падает интернет в офисе, все магазины остаются без IT. Несмотря на два канала, такое случилось как минимум один раз, когда около офиса решили выкопать яму менять трубы.
Соответственно, следующим шагом был переход в отказоустойчивый ЦОД. Выбирали довольно долго. Сейчас у нас 10 физических серверов, на которых развёрнуты виртуалки. При сбоях сервисы умеют мигрировать между машинами, есть тонкая балансировка нагрузки. В сезон резко вырастает требуемая мощность, мы докупаем машины, потом через месяц снимаем аренду — очень удобно в плане экономии. СХД для базы нет, она крутится на одном из серверов, куда мы добили полку с SSD-дисками. Когда начали упираться в долгие просчёты по итогам периода, попробовали кластер с мидрейнджевой СХД, но оказалось довольно дорого для наших мощностей пока, отказались.
В итоге появилась независимость от инфраструктуры офиса в плане критичных процессов: если что-то случится, у нас пропадёт работа дизайнера до последнего бекапа, пара табличек в XLS — и всё. Все коммерческие процессы будут восстановлены почти сразу, как появится новое железо. Кстати, насчёт железа — на Новый Год мы дублируем все узлы не только в IT-структуре с серверной стороны, но и физически. Если в магазине отказывает терминал, на складе прямо там уже лежит точно такой же преднастроенный системный блок, который можно просто подключить вместо вышедшего из строя и не разбираться, что там глючит — винда, конденсатор на материнской плате или слетевшие настройки.
Аутсорс
У нас есть своё IT-подразделение и внешняя компания-аутсорсер, которая дополняет его. Самая главная вещь в схеме работы — удалось реализовать ситуацию, когда нет переброски мяча между нами и внешними сотрудниками.
Для начала мы чётко разделили сервисы. Например, если есть физический сервер, то на нём:
- Система виртуализации (администрирование и мониторинг на аутсорсе)
- Win-машины (администрирование и мониторинг на аутсорсе)
- На одной из машин есть СУБД (администрирование и мониторинг на наших ИТ-специалистах)
- Базы 1С (администрирование и мониторинг внутри у нас)
- Резервное копирование баз (аутсорс).
И так далее. Затем мы очень чётко прописали каждую цену за каждый узел и SLA к нему. Например, если в магазине выходит из строя компьютер:
- В пик сезона — должен лежать преднастроенный системный блок, который нужно просто переподключить.
- В остальное время — SLA 4 часа на восстановление работы этого узла в базе данных.
Сервисы разделяются по уровням:
- Сервисы уровня рабочего места (например, поддержка АРМ кладовщика).
- Уровня площадки (сервис сетевой печати в офисе компании).
- Есть сервисы уровня компании (сервер терминалов в ДЦ).
У каждого сервиса есть свои показатели: время реакции, время готовности, стоимость, «штраф». Сервисов очень много, и показателей соответственно тоже. Система оттачивалась годами, и простое перечисление сервисов занимает порядка 30 страниц. Парни утверждают, что такой подход позволил им избавиться от хаоса в голове и предлагать чётко то, что нужно, ещё и другим компаниям.
Пример, как действует активный SLA (обратите внимание, что когда речь про юрлицо, стало возможным устанавливать вычеты за косяки):
- SLA по сверхважному сервису отвечает показателям: режим работы 12/7, время реакции 6 минут, время готовности 1 час.
- 1 час простоя для сверхважного сервиса — минус 100% ежемесячной стоимости сервиса.
- 2 часа простоя для сверхважного сервиса — минус 200% ежемесячной стоимости сервиса.
- Далее вычет из бонуса продолжает расти линейно, но не так быстро — 8 часов — 300%, и так до 400%. При этом стоимость сервиса — это оплата за него аутсорсерам, а не стоимость сервиса для компании. К примеру, если обслуживание одного компьютера в магазине стоит 700 рублей, выход его из строя на смену — 2100 рублей.
Несмотря на то, что магазин за это время недополучает прибыль (вторая касса не работает), это никак не связано с IT-аутсорсингом и его оплатой — парни просто не могут отвечать за такие вещи. До такой логики мы шли довольно долго, и нам нужно было постоять и на своём месте, и на их месте, чтобы это понять.
Вова (наш бывший админ, который как раз и основал bitmanager.ru) рассказывает, что благодаря такой работе у него выросли показатели качества по всем заказчикам. Точнее — он хорошо понял, что нужно рознице. Нет, сначала, конечно, он бился головой о стену, конечно, но потом научился контролировать процессы изнутри с помощью системы сбалансированных показателей. Еженедельно подводится итог всех тикетов, ежемесячно по всем тикетам подсчитываются показатели SLA, и при необходимости рассчитывается штраф или бонус.
Дальше стало ещё интереснее. Дело в том, что в зависимости от сезонности бизнеса меняется загрузка нашего внутреннего IT-отдела. И оказалось, что некоторые части инфраструктуры можно отдавать на аутсорс, например, под Новый Год, когда силы ИТ нужны на других участках, а потом забирать обратно «под своё крыло» в конце пика. Потому что это экономит затраты. В итоге в начале каждого месяца аутсорсеры пересчитывают все узлы и сервисы, которые под их ответственностью и выставляют счёт. Соответственно, такой подход оценки каждого сервиса и узла также означает, что ни у кого в подразделениях нет «свободного» железа или лицензий — всё то, что требует поддержки, денег или является неиспользуемым активом, возвращается «на базу», откуда его можно куда эффективнее использовать.
Надо сказать, что им помогло то, что на начальном этапе, когда мы только строили свои отношения, внешний саппорт думал, что достаточно иметь сервис выездного админа. Но нарушения SLA вызывали штрафы или лишения бонусов, поэтому они адаптировали свои процессы под поддержку розницы. Сейчас работают как часы — каждый тикет ставится в панель саппорта, приоритезируется и под него выделяются нужные ресурсы. Последний выход из SLA был более года назад.
P.S. Ну что, рассказывать дальше наши приключения, или ну его нафиг, эту IT-инфраструктуру среднего бизнеса, которая и так всем знакома?
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий