Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Держать своего «сетевика» или отдать всё на аутсорсинг? И как выстроить с ним отношения?
Нужно ли дополнительно стимулировать, мотивировать и контролировать такого сотрудника или возможно изобрести какой-то свой способ, чтобы управлять процессом?
Как не навредить своему бизнесу?
Нужна ли экономия на всём и везде?
Статья аккумулирует многолетний опыт общения системного администратора с разными заказчиками. Почитать будет полезно как исполнителям, так и заказчикам. Первым, чтобы знать, что требовать и где «соломки подстелить», вторым, чтобы не придумывать «сферического коня в вакууме», а реально подходить к делу при постановке задачи и оплате.
Приходящий специалист или штатный сотрудник на весь рабочий день?
Важное замечание.
Мы не говорим о крупных аутсорсинговых компаниях и системных интеграторах, где практикуется целенаправленный сбор и подготовка специалистов, с целью последующего предоставления услуг.
Хотим мы этого или нет, но российское IT до сих пор состоит из малых организационных единиц. Даже в крупных городах-миллионниках большую роль играют небольшие предприятия (звучит как каламбур). Какая-нибудь торговая фирма до 200 человек, работающая частично на «удалёнке» — для многих российских компаний это предел самостоятельного развития бизнеса с нуля.
Такая компания не может нанять себе целый штат сотрудников, занимающихся исключительно сетевым сегментом. И, чтобы воспользоваться услугами «сетевика», приходится искать хорошего специалиста, работающего по договору.
Когда штатный сотрудник превращается в приходящего специалиста
У многих сетевых администраторов и инженеров достаточно высокие шансы перейти в разряд приходящего специалиста с выгодой для себя.
- При настройке сетевого оборудования гораздо больше подходит принцип «Работает? Нормально работает? — Не трогай!». Некоторые вещи, такие как настройка маршрутизации, испортить достаточно просто, а быстро разобраться в проблеме не всегда получается. Поэтому рабочий день у сетевика в малой организации часто превращается в «просиживание штанов», и на него стремятся повесить любые технические работы от вкручивания лампочек до пожарной сигнализации. Когда ему это надоедает, и чтобы сохранить себя в профессии — он либо уходит из компании, либо переходит в разряд приходящих админов.
- Сетевые технологии, как область знания, достаточно консервативны. Это не разработка ПО, где каждые полгода рождается очередной «кадавр», и всё срочно начинают соображать, что с этим «чудом» делать, мигрировать на него или нет? Сетевое оборудование может годами работать без кардинальных изменений. И если не выходит новых прошивок, то бывает, что и делать особо нечего.
- Хочется чего-то нового. У штатного админа даже не в малой, в средней компании часто ничего особенного не происходит. Один и тот же набор оборудования, купленного «на века», одна и та же корпоративная политика, не меняющаяся годами из разряда «этих пускать, а этих — блокировать», в общем тоска.
Отлично, когда всё «тихо едет, не скрипит», но, в то же время особых возможностей для саморазвития не появляется. А в IT сфере как: если не изучать что-то новое, то сегодня ты востребованный специалист, завтра — вроде ещё ничего, послезавтра — отстал и выброшен на обочину.
Преимущества превращения в приходящего админа/инженера
Во-первых, больше шансов с толком использовать своё время. Не просиживать штаны или вкручивать лампочки, попутно помогая дамам из бухгалтерии формировать отчёт, а успевать выполнить заявки большего числа организаций, и получить суммарно больший доход.
Во-вторых, большее разнообразие. У кого-то новый маршрутизатор появился, с которым надо разобраться, у кого-то сеть целиком переделывают, где-то требуется переделать WiFi, потому что старая схема не справляется с нагрузкой...
А это действительно выгодно?
На сегодня сложилась практика, что приходящему админу можно платить меньше. С другой стороны, эта же практика стимулирует заказчиков заключать контракты с внешними подрядчиками, проще говоря, искать приходящих специалистов
На данный момент ситуация, когда выгодней свой постоянный сетевой администратор на полный рабочий день, не так уж часто встречается. Разве что текущий сотрудник работает суперкачественно за предельно маленькую зарплату и от него совершенно не требуется повышать свой профессиональный уровень. И всё равно начальство нет-нет да задаётся вопросом: «А так ли уж нам нужен этот «сиделец на одном месте»?» Потому поиск хорошего приходящего профильного специалиста взамен штатного сотрудника — наиболее распространённое решение подобных противоречий.
С другой стороны, за всё приходится платить.
Например, какие-то мелкие проблемы, которые в принципе не мешают в работе — проще проигнорировать, чем лишний раз вызывать приходящего админа.
Если посмотреть с точки зрения самого приходящего специалиста — недостатки «сидения в офисе» описаны выше.
В целом на вопрос о выгоде можно ответить кратко: «Для всех по-разному».
Ночной режим
Это отдельный вопрос для обсуждения, который каждый решает по-своему.
Бизнес часы — это как раз время, когда большинство организаций работает и зарабатывает деньги. Поэтому проводить какие-либо действия, которые могут затронуть деловой процесс — нежелательно. Приходится смещать основную активность на нерабочее время. С этим приходится мириться, подстраивать рабочий график сетевого инженера. В этом плане с приходящим сотрудником проще.
Итак, взвесив все «за и против», организация решила вместо штатной единицы нанять приходящего админа/инженера.
Какие при этом могут возникнуть нюансы?
Если не брать в расчёт какие-то юридические и бухгалтерские вопросы, связанные с оформление трудовых отношений и выплатой вознаграждения за труд, то основная проблема — в желании одной из сторон не переплатить лишнего.
Давайте посмотрим на проблему с нейтральной точки зрения.
За что я вам плачу деньги если всё работает???
За что в общем платить, оно понятно — за обеспечение… и за поддержание… и за устранение… и так далее.
Другое дело, какой критерий выбрать.
Вариант с почасовой оплатой
Сколько времени человек за работой провёл, столько денег получил.
Справедливо, не правда ли? Не будем спешить с выводами....
Приходящие специалисты — живые люди. А при такой схеме оплаты возникает соблазн работать не особо напрягаясь. Не так чтобы очень медленно, и тем более, не бездельничать, потому что это сразу заметно. Но всё выполнять по принципу: «идёшь в тайгу на день, бери продуктов на два...»
Чем плохо — организации всё-таки работать надо. Если каждая минута на счету, то такой «неторопливо-обстоятельный подход», при котором основные бизнес-процессы простаивают, может обойтись дороговато. Но некоторые не особо умные руководители это не понимают и не стремятся понять.
Если посмотреть с точки зрения самих специалистов, то тут другая беда. При таком подходе абсолютно не учитывается этап подготовки, приобретения знаний, поиска информации и так далее. Заказчик готов платить только за завершающий момент, когда приходящий специалист что-то вводит на клавиатуре в серверной, но не берёт в расчёт время на поиск решения. Хорошо если задача простая из разряда «взял и сделал». Но если надо найти причину проблемы или выбрать оптимальный вариант и при этом желательно не ошибиться, тут вариант: «вот гвоздь, вот подкова, раз, два и готово!» — далеко не всегда подходит.
Получается, что высококлассный специалист, решающий сложные задачи, подразумевающие «домашнее задание», будет зарабатывать меньше, чем простой начинающий админ, которые выполняет только очень простые поручения.
В случае с крупной аутсорсинговой компанией эту проблему можно решить за счёт перераспределения доходов от большого числа сотрудников, например, в виде доплаты за квалификацию. Но в случае с фрилансером-одиночкой этот вариант не возможен. Приходится изображать кипучую деятельность. Такие временные «накрутки» делаются отнюдь не от хорошей жизни.
Оплата по количеству вызовов
Ещё один, казалось бы, справедливый вариант оплаты. Сколько раз пришёл, столько денег получил. По мнению недалёкого начальства — стимул побольше работать, а не «просиживать штаны».
В целом схема чем-то похожа на повременную оплату, но есть большое отличие. Дело в том, что просто так приходящего специалиста не вызывают. Обычно для этого должно что-то случиться, например, пропал доступ в Интернет, перестала ходить почта или вообще легла вся сеть. И тут как нельзя вовремя появляется нужный специалист, который быстренько всё чинит. Понимаете, куда всё клонится?
При такой схеме оплаты приходящий «волшебник» не просто не заинтересован обеспечивать бесперебойную работу, ему выгодно, когда что-то постоянно ломается, что-то не работает, чего-то не хватает. Ещё это выгодно некоторым другим сотрудникам в организации, которые могут побездельничать во время сбоев. В общем, всем хорошо, кроме бизнеса.
Прямо как в репризе Райкина «Дефицит»: «Ты меня уважаешь, я тебя уважаю, мы с тобой уважаемые люди».
Ну а если ничего не ломается и «оно само всё работает», то такую «поломку» можно организовать искусственно. Говоря языком «героя» из репризы Райкина: «Пусть всё будет, но пусть всегда чего-то не хватает».
Некоторые владельцы бизнеса сами помогают в решении такого «вопроса». Если в финансовая политика организации определяется словами «нахаляву» и «поменьше платить», то начальство само ставит задачу приходящему админу выбрать оборудование как можно дешевле: «У нас тут не Москва (не Париж, не Нью Йорк, не «Кремниевая долина» и т. д.) и крутые «навороты» вроде повышенной надёжности и этой самой безопасности нам не нужны...»
В итоге приобретается самый дешёвый вариант из серии NoName, и это всё будет постоянно сбоить в силу не особо удачного аппаратно-программного решения. Ещё одна схема для «экономии» — установить самую слабую и простую модель «для домашнего пользования» под гораздо большую нагрузку офисной сети и наслаждаться постоянными «зависаниями». Зато никто не скажет, что приходящий админ ничего не делает. Ещё и деньги при покупке оборудования сэкономил.
На самом деле инициатором и проводником такой разрушительной «политики» является сам жадный заказчик, а исполнителю остаётся послушно «взять под козырёк» и исполнять пожелания, ведь как известно: «Заказчик всегда прав».
А начиналось всё с той самой якобы «справедливой» схемы оплаты: «Не потопаешь, не полопаешь» ...
Ни минуты простоя!
Поклонники данной схемы приводят пример Генри Форда, который платил техникам, обслуживающим конвейер только за время, которое они «бездельничали» (а конвейер работал). Если конвейер ломался, то техники за время ремонта оплату не получали. Считалось, что это должно побудить людей работать более качественно и всё предусмотреть заранее, чтобы было меньше поломок.
Казалось бы, что здесь плохого. Сразу «взять и настроить всё как надо», «нормально делай — нормально будет» и много других лозунговых истин прямо голосуют за такой подход.
Однако исповедуя данный принцип, заказчик невольно подталкивает исполнителя к самому примитивному подходу к работе.
Ещё хуже, когда заказчик открывает для себя библиотеку ITIL, и начинает манипулировать кучей терминов, плохо представляя, как на самом деле это всё работает.
Первое, что при этом происходит — Service Level Agreement или сокращённо SLA на деле превращается в примитивный инструмент «закручивания гаек».
Заказчик берёт самый высокий уровень, предназначенный для крупных предприятий, где высокий уровень отказоустойчивости и общей «живучести» системы достигается за счёт дублирования, резервирования и других мер, базирующихся на применение избыточности. И начинает слепо транслировать обретённое «знание» на свой местечковый уровень, на домашние роутеры, NoName коммутаторы, обжатые вручную патчкорды и другие «прелести» среднего и малого бизнеса.
Примечание. Service Level Agreement или SLA (соглашение об уровне сервиса) — документ, описывающий подход компании к организации ИТ процессов. Часто под SLA в более упрощённом понимании подразумевают договор, устанавливающий параметры качества предоставляемых бизнесу ИТ услуг.
Данный документ используется для двустороннего регулирования взаимоотношений между заказчиком и исполнителем,
В SLA закрепляются договорённости об условиях предоставления услуг (сервисов), перечень таких услуг, а также правила, которые заказчик обязан соблюдать при эксплуатации предоставляемых сервисов. Поэтому SLA служит не только для контроля качества ИТ услуг, но и устанавливает допустимые ожидания потребителей.
В случае примитивного подхода это выглядит примерно так: «А обеспечьте-ка мне уровень простоев не более 30 секунд в год! Потому что Я так хочу, у нас с вами будет вот такой SLA. Всё, работайте, время пошло!», — и… собственно, это надо как-то исполнять.
Например, поставить «watchdog» и лечить проблемы перезагрузкой устройств вместо того, чтобы разобраться в причинах перебоев, максимально долго оттягивать процесс модернизации ИТ инфраструктуры и так далее.
Да что там модернизация, даже простое обновление прошивки Интернет-шлюза — это же «несанкционированный простой!», и поэтому «пока потерпит» ...
В первую очередь при таком подходе жертвуют заботой о безопасности. Будет попытка взлома или DDoS атаки — неизвестно, а штраф за неудобство или перебои во время настройки исполнителю точно прилетит. Поэтому «как работает — так работает, и вообще, кому эта контора нужна, чтобы её взламывать» ...
Во вторую очередь в жертву приносятся работы по профилактике, модернизации и так далее. Например, замена кулера в коммутаторе — это же остановка на целых 10 минут! Поэтому выкручиваем «холод» в кондиционере на самый максимум и продолжаем «работу».
В итоге всё обслуживаемое сетевое хозяйство кое-как существует, пока технический долг по обслуживанию системы не достигнет определённой черты. И происходит количественно-качественный переход от кое-как работающей системы к полностью нерабочей.
Или до первого серьёзного взлома или мощной DDoS атаки. Тут уж комментарии излишни.
А как надо?
Обозначить проблему, но не предложить внятного решения — означает сделать только половину работы.
Увы, как известно, «серебряной пули» не бывает, нет готовых решений по принципу «раз-два и всё хорошо».
Однако можно выделить несколько рекомендаций по взаимодействию между приходящим амином/инженером и заказчиком, который хочет получить приемлемый результат.
- Не смешивать текущую работу по поддержанию сетевой инфраструктуры (в том числе устранение сбоев) с профилактическими работами и, тем более, с модернизацией сети. Для поддержания сети в рабочем состоянии должно быть заключено соглашение с разумными критериями, составленными на основе понимания конкретной ситуации. Если требовать для компании, работающей по 8 часов 5 дней в неделю того же уровня обслуживания, как и для крупных ЦОД, работающих 24/7/365 — это может вылиться в дополнительные расходы: явные или скрытые.
- Должны быть выделены часы для профилактических работ, их состав, длительность и время проведения должны быть заранее спланированы и согласованы.
- Для модернизации сети необходимо составлять отдельный проект. Речь не идёт о разовых заменах сгоревшего или сильно устаревшего оборудования. Но если меняется сетевой шлюз и это найдёт своё отражение в работе организации — это уже повод для описания решения, составления сметы на выполнение работ, акт приёмки и написания других полезных документов.
Понятное дело, что бумажная работа мало кому нравится, но зачастую без неё никак.
Но даже несмотря на все подписанные документы, важным моментом является взаимное доверие и стремление к сотрудничеству.
Иначе любые трудовые отношения будут только во вред.
И, разумеется, в рамках короткой статьи нельзя описать все нюансы, которые встречаются при достаточно сложных бизнес-процессах ИТ инфраструктуры.
Например, такой прекрасный сюжет, когда заказчик требует от приходящего админа наиподробнейший отчёт, на составление которого уходит больше времени, чем на решение технических вопросов с сетью, вместе взятых.
Или когда бухгалтерия заказчика «боится» заплатить специалисту слишком много, слишком часто: «А вдруг налоговая придёт и нас всех посадит в тюрьму? Нет уж, давайте-ка, раз вы уж такой хороший специалист, устраивайтесь к нам как положено, на целый день, по трудовой… А маленькую зарплату мы поднимем… потом… когда-нибудь, если «наверху» деньги выделят...»
Чисто технический момент
Компания Zyxel старается предложить для приходящих админов, инженеров (и не только для них) полезные инструменты, которые всегда под рукой.
Среди них стоит отметить Zyxel Nebula и Zyxel CNM SecuReporter.
Кому удобнее работать с Zyxel Nebula:
- Приходящим специалистам удобно использовать Zyxel Nebula — управление, мониторинг, локализация проблем (кроме аппаратных) — все доступно не вставая с дивана. Остаётся только лично являться на объект с важным лицом, чтобы изредка смонтировать оборудование, подключить кабели и патчкорды, и можно поехать домой все настраивать и конфигурировать. (Иногда этот этап можно поручить дежурным админам заказчика).
- Штатным сотрудникам Nebula позволяет не ездить на удалённый объект по любой нужде (не посещать ЦОД, не ходить в серверную и вообще пореже куда-либо перемещаться) и часть времени работать из дома без потери эффективности. Все настраивать дистанционно, мониторить дистанционно. Даже такие мелкие, но очень ответственные задачи вроде подключения точки доступа WiFi путём втыкания патчкорда в розетку можно поручить любому более или менее технически грамотному сотруднику, а настраивать уже удалённо через «облако».
Для тех, кто любит «чистое небо» (то есть всё выполнять самостоятельно вручную) — есть локальное управление всем «железом» Zyxel, даже тем что поддерживает Nebula. И переключение из облака в режим локального управления и обратно — возможно в любой момент.
Zyxel CNM SecuReporter — это облачная интеллектуальная служба аналитики и отчётов с функциями сбора и корреляции данных, разработанная для межсетевых экранов Zyxel (в том числе в Nebula). Он предоставляет сетевым администраторам централизованное представление о сетевой активности. Подробнее здесь.
Полезные ссылки
- Центр обучения Zyxel
- Новостной канал в Telegram
- Телеграм-чат поддержки для специалистов
- Форум для специалистов
- Свежие новости в Facebook
- Наш YouTube
- Реализованные проекты
- Security Service Cloud CNM SecuReporter
- Центр управления — Nebula Control Center (NCC)
