Pull to refresh

Comments 26

А как вы решаете проблему отказов софта? Вот, например, была лет 10 назад история у vmware, что 29 февраля лицензия сказала, что она не лицензия и выключила все виртуалки. Вам говорят "включай", а софт говорит "нифига". Чей это даунтайм?

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

А как вы определяете, что это баги производителя, а не кривые руки персонала? И как вы это доказываете заказчику? (Если вендор признал, то просто, но до этого момента?)

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

Это типичная ошибка жадного аутсорсера (ну, или когда руководитель делает аутсорсинг ради бонуса, а не результата), и честно говоря, они после этого сами себе буратины — квалифицировааного контроллёра (или трёх, для избыточности и кворума) нужно оставлять.
Да, это как правило прописывается в договоре, нарушил sla восстановления = штраф. А потом уже доказывай, что виновен вендор/провайдер, любая третья сторона, даже уборщица со шваброй.
Спасибо за вашу статью и шаблон.

Сам ранее работал в аутсорсинговой компании системным администратором, потом открыл свою компанию, и наступил на эти грабли. Нужно было перенести почту из Shared хостинга на G Suite (в блэк листы попадали все время из-за соседей, письма не доходили и тд). Изначально было много всего разбросанно — у пользователей IMAP аккаунты, по часть писем в 2-3 PST архивах, и тд.

И сам сервер у заказчика очень медленный (на бюджетном хостинге в Облаке, перезагрузка длилась около 2 часов. Да!).

Я начинаю письма из PST перемещать в IMAP аккаунт — у всех начинает тормозить сервер, все подвисает. И тд. В общем говорю — нужно делать в нерабочее время, это будет отдельная оплата — на что получил ответ «делайте в рабочее время». Попытался объяснить что если я это буду делать в рабочее время у вас сотрудники работать не смогут, скинул план работ (что буду делать, сколько времени займет), по пунктам. И стоимость работ.

В ответ мне сказали — мы с вами не проговаривали работу в нерабочее время, и что она отдельно оплачивается. И тд.

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

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

В ответ мне сказали — мы с вами не проговаривали работу в нерабочее время, и что она отдельно оплачивается. И тд.

Так что мешало делать операцию в рабочее время? Руководство ведь было предупреждено о последствиях.
Я просто хотел это сделать, чтобы закрыть этот вопрос (были проблемы с почтой, сотрудники постоянно жаловались на то что письма не доходят подрядчикам и тд., мне это слушать постоянно не хотелось), и к нему не возвращаться.

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

В целом — хороший урок, который пришлось бы раньше или позже пройти.
Очень крутая статья, спасибо что выложили, будем использовать как образец при случае.
Мне вот интерестно, как вообще принимаюся решения, что такие документы разрешают выкладывать в открытый доступ, это-же вроде интеллектуальная собственность. Ну т.е. это вы сами продавили, или позиция более высокого руководства?
Правильное ТЗ — это еще не главное конкурентное преимущество (если вы об этом). Нужно еще уметь по нему работать. Поэтому копирования не боимся. Если кому-то будет полезно, значит не зря писала статью. Очень рада, если помогла!
Да, я полностью согласен что открытость только улучшит ваш имидж. Вопрос был больше о согласовании этого решения — «Давайте выложим наш контракт в открытый доступ» внутри вашей компании. Это пошло снизу или сверху? (Наверняка же это противоречит стандартному трудовому договору)
Документ не является конфиденциальным. Это стандартная часть ТКП.
Кстати еще вопрос — а на английском языке если ли вариант подобного шаблона ТЗ?
К сожалению, английской версии пока нет.
В «Выдернул жёсткий диск, что-то записал, ВОТКНУЛ ЕГО НАЗАД, выдернул второй, записал, поставил, выдернул третий. » — верю. В остальное (не возможность скрыть кривые ручки персонала) — не верю.

ЗЫ А как вообще кто-то окромя сертифицированного инженера попал к стойкам с оборудованием?
А вот этого сказать не могу. ЦОД общественный, увидели случайно, что в соседней ячейке происходило. Но случай, конечно, красноречивый.
Да уж, нагляделся я на это глобальное администрирование. Когда заключается контракт с I.L или Ма… ор, те заключают с субподрядчиками, а те ищут инжинеров на авито или друг у друга. Звонят из Караганды в Краснаярск — «у тебя никого в Иркутске нету за 400 р/ч».
Но и головная поддержка жжёт. Заявка-нет сети на рабочем месте. На месте выясняется, что сдох порт на каталисте. Все порты заняты пачкордами, половина в дауне. Звонок в голову сапорта «что делать?» Ответ «мы хз, какие порты нужны-какие нет, передадим в другой отдел, они позвонят»- и звонят, часов через 5. А это инцидент, и оплата за час, и статус никто не повысит и заявку не закроет. И что делать инженеру, сидеть 5 часов за часовую ставку или уезжать и приезжать.
Отличная статья, спасибо!
Было бы очень интересно почитать о других трудностях, которые могут возникнуть во время работы с клиентом.
Спасибо, буду писать еще. Трудности, они очень вероятны с обеих сторон, если нет прозрачности в процессе и понимания чего хотим на выходе.
Мы тоже решили открыть свою компанию, занимающейся обслуживанием it инфраструктуры компаний, но пока мы на стадии зарождения.
Было бы интересно ещё почитать о ваших этапах становления, как нарабатывали клиентов и с какими пришлось сталкиваться.
Так сказать, хочется быть готовым ко всему)
Sign up to leave a comment.