Заказчик всегда прав или клиенты с лапками
Думаю каждый из вас хоть раз в жизни видел мемы про заказчиков. Жизнь моя так повернулась, что и у меня сохранилось пару историй про непутевых специалистов из контор, где мне посчастливилось заниматься внедрениями различного программного обеспечения. О них я вам и поведаю сегодня!
Ну как отказать в помощи, когда у них лапки?
Вся соль работы инженера по внедрению
В недалеком прошлом на одной из первых работ меня привязали к одному из продуктов в сфере информационной безопасности, а конкретно системе класса UEBA. Для непросвещенных — это метод выявления вредоносной активности через анализ поведения пользователей и объектов в сети.
Первые внедрения действительно проходили в онлайне, пара встреч для планирования работ и знакомства. Позже начались «трудовые будни», когда заказчик выдавал удаленный доступ к своим ресурсам и наблюдал за работой сложа руки, но любой сказке приходит конец…
Компании с закрытым контуром вошли в чат. Оформления пропусков — это отдельная история, ведь каждый визит в офис клиента требовал подачи уймы заявок. А далее ты проводишь по 5–6 часов за каким-нибудь компьютером, который никем не используется и покрылся слоем пыли. И не дай бог ты куришь — тогда тебе после каждого перерыва нужно искать того самого Ивана Ивановича, чтобы компьютер разблокировали и везде снова залогинились.
«А вам нужна была Ubuntu с русским языком? Блин, простите»
Была у продукта компании некая особенность — в одном из этапов установки требовался русский язык, о чем подробно сообщалось заказчикам на пресейл встречах, но не все слышали такие, «мелочи».
Наступил день «X», мы подключаемся с коллегой для установки и настройки, проводим около полутора часов в ожидании пока скрипты развертывания отработают, и тут выясняется, что Ubuntu, установленная на виртуалку, установлена исключительно с английским языком в раскладках.
Моему «ликованию» не было предела, когда представитель клиента заявил, что не сможет здесь и сейчас исправить эту недоработку. Ну и, конечно же, что ему об этом никто не сообщал, и мы сами виноваты. Внедрение было отложено, встреча переназначена, руководство пришло с вопросами на тему «а как же так вышло, что заказчик не в курсе о подробностях».
Мы не знаем, как решить эту проблему
Задача у инженеров внедрения всегда стояла просто:
получить подготовленную инфраструктуру заказчика;
запустить скрипт установки продукта;
настроить систему на самообучение;
приехать после обучения системы и запустить её окончательно.
Но как сказал один из моих любимых героев классической литературы: «Свежо предание, а верится с трудом». Таких же принципов придерживались и клиенты.
Чисто технически — при возникновении трудностей на инфраструктуре, инженер должен попросить устранить проблему, после чего уведомить его и согласовать новый промежуток времени для установки и настройки. Но кому писано, что там в договоре оказания услуг?
Не единожды возникала ситуация, когда специалисты, подключавшиеся со стороны клиента просто не осознавали, что у них закрыты нужные порты. Это, кстати, тоже прописано в требованиях для внедрения.
Потом возникает вопрос — почему внедрение вышло из целевой рамки в N часов? А потому что тот, кто должен был просто поставить ПО и настроить его — еще и решал проблемы на инфраструктуре заказчика!
Помогите, у нас перестала работать программа
Системы информационной безопасности класса UEBA — штука привередливая и прожорливая, и ошибки в процессе ее первоначальной настройки зачастую фатальны.
Первоначально производится инсталляция чистого дистрибутива с определенным пакетом настроек, на определенном количестве инстансов. Настраивается необходимая или минимальная база фильтров поведения, правил распознавания критических отклонений и т. д.
Так как система основана на математических методах — сразу работать без каких-либо отклонений она не может, почему и работает некоторое время в тестовом режиме, собирая данные.В этот промежуток она собирает данные о всех пользователях домена, их действиях в сетке компании, отправленных письмах, получателях этих писем, инициации доступа к какому-то ресурсу сети Интернет, сетевому диску и прочим причастным.
Минимальный рекомендованный промежуток для обучения — 2 недели, идеальный — месяц. За это время количество данных, которые поступают на хранение, достигает огромных цифр. Соответственно, чем больше инстансов развернуто — тем больше памяти присваивает этот осьминог. И есть одно маленькое «но» — ротация логов/данных, которые обрабатывает система. Если немного не рассчитать и настроить её неправильно — обучение пройдет некорректно, и вся работа по внедрению требует повторения с момента установки ПО.
Так и случилось в одной крупной компании. Спустя неделю после первоначальной установки и запуска обучения, с нами связался технический специалист и сообщил эту фатальную новость. К сожалению, сотрудник, который совершал выезд к этому заказчику, на тот момент уже уволился. Видимо не сильно горел желанием в последние рабочие дни в компании выкладываться даже на 50%.
О чем же я?
Мы с вами можем выступать в этой постановке с любой из сторон — заказчик/исполнитель. Все мы люди, все можем допускать ошибки.
Данная статья написана исключительно в развлекательных целях и не имеет цели оскорбить и задеть кого-либо. В конечном итоге цель у всех одна — получение выгоды. Но на пути к цели — давайте оставаться людьми и помогать друг другу, не перебрасывая ответственность на другого человека.
