5 октября 2014 в 19:03

Как мы отучили аутсорсинг перекидываться мячом со внутренним ИТ-отделом



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

Началась история с того, что нам понадобилась централизованная система с фермой терминалов. На тот момент у нас было порядка 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-инфраструктуру среднего бизнеса, которая и так всем знакома?
Автор: @Milfgard
Мосигра
рейтинг 586,17
Настольные игры и здравый смысл

Комментарии (56)

  • +21
    вводить такое сразу — ад.
    дорасти до такого — достижение.
    реализовать такое — крутизна.

    молодцы!
    • +3
      Спасибо. У вас двумя первыми строчками получилось донести то, о чём мы спорили в прошлом топике. Да, многие вещи вводить сразу — тотальный кошмар, и нужно сначала пройти пару «линек» до них.
      • +1
        Большинство остаётся на одной из предыдущих ступеней :)
  • –2
    (чисто формально) По КЗОТу штрафы запрещены. Даже если они маскируются в виде «половина зарплаты выдаётся премией».
    • +12
      Штраф — очень пользовательский термин. Скажем так, недобонус. И это, КЗОТ — он про сотрудников. Тут речь про оплату контрагента.
      • –1
        Ну вот если «недобонус» вычитается из обычно оплачиваемой части, то человек с лёгкостью выиграет в суде, если покажет, что в компании общепринято платить пол-зарплаты премией.

        Простые доказательства:
        * История зарплат, где ежемесячно «премия» примерно одинакового размера
        * Объявления о вакансиях, где в качестве ЗП называется сумма с премией
        * Свидетельства сотрудников (парочку среди оштрафованных человек легко найдёт)
        • +9
          Вы точно поняли, что это про контрагента-юрлицо?
          • –6
            Я точно понял, что это про сотрудников этого конагента-юрлица. Или вы выплачиваете «бонусы» юрлицам?
            • +12
              Мы к сотрудникам этого юрлица не имеем никакого отношения. Сумма оплаты по договору в месяц зависит от эффективности работы контрагента, исполнения KPI, если угодно. Стало понятнее?
              • +9
                А, ок. Юрики между собой могут любые условия изобретать.
                • +3
                  Сейчас уточню в топике, почему это важно, спасибо.
  • 0
    Поясните, пожалуйста:
    •В пик сезона — должен лежать преднастроенный системный блок, который нужно просто переподключить.
    •В остальное время — SLA 4 часа на восстановление работы этого узла в базе данных.
    Вы что, после сезона их выкидываете?
    • +1
      Они концентрируются обратно у контрагента, как правило. Пик бывает не только у нас, но и у других его клиентов, иногда — в противофазе, летом.
      Кроме того, эти же машины и лицензии используются для развёртывания других отделов в пик разработки, например.
      • 0
        Т.е. у Вас железо (частично) не принадлежит Вам?
        • 0
          Резервное — не уверен, боевое — точно наше. Вообще, если можно арендовать что-то на время или вернуть — мы воспользуемся из-за неравномерного характера продаж.
          • 0
            А если ломается железка, вместо неё дают не Вашу, а арендованную, что происходит с Вашей?
            Если резервное Ваше — какого хрена его отдают другим клиента Вашего контрагента???
            • 0
              Я к тому, что при замене она может становиться нашей.
              Наша чинится и отправляется на наш склад. Когда потребуется — вводится в строй или встаёт в резерв.
              • 0
                Понятно, спасибо!
              • 0
                Много у вас на складе оборудования «пылится»?
                • 0
                  Не очень, мы же постоянно расширяемся. Но, чувствую, вопрос ещё встанет.
      • 0
        Так-то в этом самая суть «облачных» технологий.
        Не что-то где-то там в сети.
        А нужный ресурс, к которому можно при надобности добавлять ещё такой же. А при ненадобности — отключать.
    • 0
      В пик сезона системник меняется как только использовался.
      Вне пика сезона — можно неделю и потерпеть с созданием резервного системника
  • +2
    Правильные вещи излагаете. Жду продолжения.
    Спасибо!
  • 0
    Да, продолжение нужно. Интересны не только «приключения» но и «выводы».
  • +6
    Ну что, рассказывать дальше наши приключения, или ну его нафиг, эту IT-инфраструктуру среднего бизнеса, которая и так всем знакома?


    Очень интересно! Пожалуйста, продолжайте и, если не сложно, осветите следующие вопросы:

    1) Как организована работа над повышением качества работы ИТ-инфраструктуры? Сейчас вы описали, как ваши аутсорсеры исправно лечат аварии, а что (и как) они делают, чтобы число аварий уменьшалось со временем? В их ли интересах вообще уменьшать количество аварий или нет?

    2) Предусмотрена ли вашим договоров ответственность за сохранение данных компании. Что будет, если вдруг обнаружиться, что из бекапа невозможно что-то восстановить?

    3) Кто первая линия технической поддержки? Т.е. кто принимает звонок от пользователя и ведет учет времени обращения, реакции и устранения инцидента? Если это делает аутсорсер, то как вы верифицируете правильность предоставляемого им отчета?

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

    5) У вас много региональных магазинов. Как организована их поддержка на местах?

    6) Есть ли какие-то рычаги влияния у ИТ-аутсорсера на ваш ИТ-отдел или на решения в компании? Из вашей статьи следует, что вы загнали аутсорсера в достаточно бесправное положение и тем самым прекратили «футбол». Может ли аутсорсер как-то повлиять на вас по договору, если, к примеру, вы не хотите заменить старый и регулярно зависающий (и генерящий тикеты) сервер? Т.е. понятно, что у вас достаточно теплые отношения с вашим поставщиком, но хотелось бы понимать, как это тепло перенесено на строки договора.

    7) «Перечисление сервисов занимает порядка 30 страниц» — это нечто подобное habrahabr.ru/company/croc/blog/187124/ или построенное на других принципах? Требует ли данный каталог от клиента наличия специалиста, понимающего все тонкости ИТ-технологий? Буду признателен, если вы осветите эту тему подробнее.

    Спасибо!
    • 0
      Сейчас многое решается благодаря тому, что мы уже давно сработались. По практике — спасибо, вопросы отличные, расскажу про опыт и случаи позже.
    • –3
      Тоже интересует первый пункт, особенно со стороны аутсорсера. По опыту знаю, что, чем лучше я сделаю свою работу, тем мне же хуже. Возникнет какая-нибудь надобность в моих услугах через год (недавний случай), но целый год я с этой организации не имею никакого дохода, а кушать хочется немного чаще :(
      • +3
        Так оплата-то за работающий сервис помесячно, а не за ремонты.
        • 0
          Ой… а ведь правда. Но мне от этого не легче, сложно сподвигнуть заказчиков пойти на основу с абонентской платой, да еще и оформлять это надо и всё такое (а я это страсть, как не люблю, прям на физическом уровне).
          • 0
            Вопрос того, как вы и заказчики умеете считать, пожалуй. Если бизнес-планирование не развито — не уговорите.
            • 0
              Это и обидно, считать умеют, планы есть, но (вездесущее но) на короткий срок.
          • 0
            Судя по тому, что написано в статье мотивация заказчиков видна насквозь. Даже пример где сутки простоя — три месяца бесплатного обслуживания.
            • 0
              Мне казалось это мотивация исполнителя, а не заказчика :)
              • 0
                Мотивация для перехода на такую систему. Заказчик получает гарантии.
                • 0
                  Хм… Спасибо за идею, в таком ключе я и не думал.
      • 0
        К сожалению, чтобы не стоят перед выбором отремонтировать хорошо или отремонтировать плохо, нужно в принципе отказаться от разовых ремонтов. Разовые ремонты — это для сервисных центров, а не для ИТ-аутсорсеров. Сегодня вы клиенту почините его сервер на разовой основе, а через полгода у него развалится рейд и не окажется бекапов (т.к. никто не проверял ни первого, ни второго) — чем вы сможете ему помочь тогда?
        • 0
          Да не стою я перед выбором, тупо всегда делаю максимально качественно, рассказывая клиенту о плюсах минусах, о том что может случиться в таких-то ситуациях, затем кратко резюмирую, перечисляя критичные и не очень вещи, описываю, что и в каких случаях он может потерять и называю цену и время необходимое для устранения, часто клиент соглашается потратить сегодня чуть больше воизбежание, но не всегда.

          > чем вы сможете ему помочь тогда?
          эм… пачиню? :)

          • 0
            Если вы находите клиентов, которым вы нужны только для разовых ремонтов и вы готовы им предложить то, что они хотят, то вы и дальше будете заниматься исключительно разовыми ремонтами. Некоторых предпринимателей невозможно переубедить никакими доводами — с ними проще не работать.
            • 0
              Обычно они меня находят. Да и они готовы обращатся периодически, но не в виде регулярного абонентского обслуживания.

              > с ними проще не работать.
              Я не настолько загружен, чтобы отказываться от заработка.
              • 0
                Заградительные цены это единственный вариант, если мы конечно не говорим про физиков и конторки меньше 5 машин, там не поможет.
                Первый ремонт может быть дешев и рекомендации это хорошо, но надо не забыть упомянуть что если случится что-то в следующий раз, то тариф будет в разы больше.
      • 0
        но как правило, клиент после 1-2-3 раза очень задумается стоит ли дальше с вами иметь дело.
        • 0
          Именно поэтому, а так же потому что мне это претит, я не делаю плохо, лучше посоветую того, кто сделает это лучше. Кроме редких случаев, когда делаю только на ту сумму, которую получу (бывает, что клиент просто не хочет или еще по каким-то причинам, не готов заплатить больше), но даже в этих, редких случаях, предупреждаю о возможных последствиях.
  • 0
    (Промах, удалено)
  • +1
    Скажи пожалуйста, почему ты публикуешь статьи на хабре в наименее «популярное» время? Чтобы снизить конкуренцию за внимание читателя?
    • +6
      В воскресенье вечером у меня обычно есть время, а на Хабре 6-7 топиков за день.
  • 0
    Спасибо за интересную тему. Я как раз немного сейчас занимаюсь оргнизацией сапорта. И в связи с этим есть вопросы.

    Судя по статье выполнение СЛА и штрафы расчитывает сам аутсорсер. Делается ли это и на стороне вашей компании, для контроля, или вы верите безоговорочно?
    Были ли ситуации когда то что насчитал аутсорсер не совпадало с вашим мнением и как такие ситуации решались/решаются системно?
    • +1
      Общий принцип — мы всем верим, но не создаём ситуации, когда злоупотребить доверием легче, чем сделать правильно. В моменты внедрения точно тикеты ставились параллельно на наш IT-отдел и аутсорс, аутсорс закрывал — по факту оценивался срок. Сейчас есть какая-то автоматизация на стороне аутсорса, но точно не скажу. Спасибо, вопрос добавляю к серии выше, покопаюсь и расскажу позже.
  • +1
    Интересно какой процент аутсорсеров, сказал бы, что вы кошмар, а не клиент, а какой — мечта, а не клиент?
    • 0
      Я бы сказал, 50/50. Потому что мы с Вовой довольно долго, частно и много обсуждали, как лучше сделать: в текущей ситуации много вклада со стороны как нас, так и его. Повторюсь, пришлось постоять на его месте, чтобы понять некоторые вещи.
      • 0
        Если вы и с другими поставщиками будете готовы также обсуждать и прорабатывать процессы, то вы для всех будете клиентом мечты :)

        Когда клиент ясно понимает что он хочет, готов бороться за качество процессов, готов смотреть в суть происходящего, последовательно идти к достижению цели, воспринимать критику и предложения, то единственное качество, требуемое от поставщика — адекватность, а все остальное в его бизнесе сделает клиент.

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


    Т.е. людей может быть настолько много, что они увидят огромную очередь в первую кассу, развернутся и уйдут? Речь вроде не про пиковые нагрузки на магазин шла в том абзаце…
    • 0
      Могут уйти. Могут просто запомнить, что тут очереди. Это и прямые потери при загрузке выше средней, и репутационные (косвенные). Но оценивать их для аутсорсера не имеет смысла, оценивается только сервис исходя из стоимости его поддержания.
  • 0
    А как вы считаете, смогли бы договориться на такую модель аутсорсинга со сторонней компанией? Тут всё таки личный фактор бывшего сотрудника сыграл.
    • 0
      Думаю далеко не с каждой, но в целом реально. Я полагаю, что клиент для аутсорса относительно крупный, деньги хорошие, так просто отказываться не захочет никто. Но многие аутсорсеры просто не захотели бы заморачиваться. Зачем, если есть много других клиентов, которых можно «разводить» на услуги получая деньги с меньшей ответственностью?
  • 0
    Снимаю шляпу и перед вами и перед вашими исполнителями! Верное дело делаете!

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное