All streams
Search
Write a publication
Pull to refresh
72
0
Иван Кормачев @ikormachev

Пользователь

Send message
Да, все верно. Но отсутствие простоев в ИТ-сервисах накладывает определенные обязательства как на аутсорсера, так и на клиента.
Вы правы, но, к сожалению, формула «штатник + аутсорс» также не универсальна и имеет свою зону применимости.

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

1) Распространена ли услуга на рынке или нет?
2) Повысится качество при передаче на аутсорсинг или нет?
3) Есть ли особые требования по безопасности к данному сервису?
4) Является ли данный сервис стратегическим для компании?

Если посмотреть на эти вопросы, то становится понятно, что аутсорсинг питания или уборки помещения — это совсем не то же самое, что и аутсорсинг обслуживания ИТ. И в случае ИТ дорого — это не значит плохо.
Это все очень теоретические рассуждения без привязок к конкретным цифрам. Мы неоднократно считали нашим клиентам как размещение в облаках, так и собственную инфраструктуру и до настоящего времени всегда выходило, что собственная инфраструктура и проще в обслуживании, и надежнее, и окупается за 2 года.

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

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


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

Что-то я не вижу, чтобы гугл или фейсбук отказывались от своих собственных серверных и обслуживающего персонала и переходили под управление внешнего поставщика услуг. И, честно говоря, не очень понимаю почему аренда железа может стоить дешевле его покупки — ведь что клиент, что поставщик покупают его +- по одной цене, а те, кто сдают мощности в аренду рассчитывают возврат инвестиций в 2 года обычно (при сроке полезного использования 4-5 лет). Конечно, для компании в 3 человека покупка облачного VPS может быть выгоднее, учитывая что такая контора может разориться со дня на день и у них просто нет денег для капитальных инвестиций. Но для офиса хотя бы в 500 пользователей я уже, честно говоря, не вижу финансовой выгоды выноса серверной.

Можете раскрыть этот тезис и показать за счет чего достигается снижение затрат?
Чуть больше конкретики по планированию аварийного восстановления: habrahabr.ru/post/225719/
Судя по всему, тов. Cobolorum, не такой уж вы и профессионал, раз с деньгами напряженка.
Предельное спокойствие и собранность — это приобретенный в процессе работы навык или он был еще перед поступлением в медицинский?
Чтобы стать хирургом, способным сходу прооперировать пациента, нужны годы не только учебы, но и практики. Чтобы стать инженером, способным сходу работать над устранением инцидентов, нужны также годы учебы и практики. А для тех, у кого еще не было должного объема практики, подумать и успокоиться прежде чем что-то делать в стрессовой ситуации (а для начинающих даже самый простой сбой — зачастую стресс) — вполне не плохой совет.

Если бы у пилотов самолетов, попавших в штопор, была возможность подумать перед тем, как начинать действия по его выводу — разбившихся самолетов было бы меньше. Жаль что у пилотов, в отличии от админов, такого времени не бывает.
А автор с его «подождать в спокойной обстановке 20 минут» живёт в мире абстрактных сферических коней в вакууме.

Ситуация: звонок в 5 утра — база данных упала. Проверяешь сервер — база валиться из-за неконсистентности данных, резервные копии по этой же причине не создавались еще с вечера, производство — непрерывное. До руководства не дозвониться. Тебе нужно оперативно принять решение: или восстанавливать базу на вечер (остановка производства, проведение инвентаризации) или попытаться починить ее (дополнительный простой и в случае неудачи все-равно восстановление). Плюс даже если ты будешь базу восстанавливать из бекапа, надо разобраться почему она упала, т.к. процентов 90, что она снова упадет. Да и вообще сообщения об ошибках в базе уже недели две как сыпятся — как же ты такое мог такое пропустить… В такие моменты в голове — полная каша и действительно нужно остановиться и подумать, чтобы не наломать с горяча еще больших дров.

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

Раньше перед тем как приступить к устранению какой-то аварии, я заваривал себе чай и спокойно пил его, обдумывая последовательность своих действий. Со временем эти последовательности перешли в определенный набор инструкций и теперь я все чаще вместо того, чтобы пить чай, открываю ящик стола, достаю их и действую по ним — работает удобнее и надежнее чем чай!
Лично меня хабр привлекал раньше единой лентой, в которой я видел только интересные мне темы. Это позволяло в одном месте получать актуальную и интересную мне информацию. Сейчас для того, чтобы не пропустить что-то, мне требуется использовать два разных ресурса, пусть и слинкованных между собой. Еще немного и я вернусь в «дохабравские времена», когда приходилось самому просматривать по утрам десяток информационных ресурсов.

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

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

По моему личному убеждению, автор статьи будет кошмарным клиентом только для тех поставщиков услуг, которые не готовы слушать, слышать и конструктивно воспринимать потребности клиентов. Конструктивное восприятие позволяет проще обрабатывать деструктивные формулировки потребностей клиентов: «давайте вы будете возмещать нам наши бизнес-потери при простое» — «ок, давайте вы их оцените и мы предложим способы, как избежать их совсем» и т.д.
Если вы находите клиентов, которым вы нужны только для разовых ремонтов и вы готовы им предложить то, что они хотят, то вы и дальше будете заниматься исключительно разовыми ремонтами. Некоторых предпринимателей невозможно переубедить никакими доводами — с ними проще не работать.
К сожалению, чтобы не стоят перед выбором отремонтировать хорошо или отремонтировать плохо, нужно в принципе отказаться от разовых ремонтов. Разовые ремонты — это для сервисных центров, а не для ИТ-аутсорсеров. Сегодня вы клиенту почините его сервер на разовой основе, а через полгода у него развалится рейд и не окажется бекапов (т.к. никто не проверял ни первого, ни второго) — чем вы сможете ему помочь тогда?
Ну что, рассказывать дальше наши приключения, или ну его нафиг, эту IT-инфраструктуру среднего бизнеса, которая и так всем знакома?


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

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

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

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

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

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

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

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

Спасибо!
Буду Вам признателен, если вы в рамках отдельной статьи опишите ваш опыт по повышению операционной эффективности: как и какие решения вы принимали при построении ИТ-инфраструктуры, как оценивали их эффективность и чем руководствовались при этом.
Тут речь не о внедрении ерп, а о том, что автор даже при построении базовой ИТ-инфраструктуры наломал всех дров, которые только можно было, и призывает всех остальных не боясь делать тоже самое. Все это выглядит как: «мы потратили кучу денег впустую на 1С, но вы также можете смело игнорировать советы вида „не забудьте сделать то-то, иначе потом придётся исправлять“, а также „мы по чистой случайности трижды чуть не потеряли критичные данные, но вам также стоит положиться на удачу и не думать о будущем“.

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity