Как мы принимаем веб-проекты на поддержку. Взгляд с точки зрения администрирования веб-серверов

Поддержка веб-проектов имеет два основных аспекта — поддержка серверой инфраструктуры проекта и поддержка программного кода. Типичный процесс принятия проекта на поддержку с точки зрения системного администратора веб-серверов выглядит так:

1. Заказчик описывает проект, обсуждает его состояние, высказывает пожелания и указывает на насущные проблемы. Мы обговариваем эти моменты до полного согласия
2. Заказчик предоставляет доступы к проекту
3. Проводится аудит инфраструктуры и настройки серверов. При этом почти всегда подключаются разработчики, которые параллельно проводят аудит кода
4. Заказчику предоставляется отчет с описанием найденных проблем
5. Обсуждается дальнейший план действий и по проблемам расставляются приоритеты

Так выглядит идеальная схема. Практика часто не столь проста и последовательна.

Опишу некоторые из подводных камней:

1. Описание проекта и проблем

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

О многих скрытых проблемах заказчик попросту не знает, т.к. прошлая команда поддержки о них умолчала или по неопытности их не заметила.

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

2. Доступы

Многим кажется, «а какие проблемы могут быть с доступами, отдал пароль и все!».

Это не всегда так.

Часто встречаются случаи, когда у заказчика нет полного перечня доступов ко всей инфраструктуре проекта. Это бывает, например, потому что предыдущие подрядчики их не передали, утаили, или же просто не могут этого сделать. Если это так, сначала мы совместно с клиентом пытаемся понять, у кого эти доступы могут быть или восстанавливаем их. Это не всегда возможно, т.к. доступ может быть утерян бесследно, и если восстановление невозможно, нередко с согласия заказчика приходится осуществлять сброс пароля, переназначение прав доступа, а иногда даже взлом или клонирование этого участка инфраструктуры в другом месте. Как пример – заказчик не имеет доступа к DNS-серверам, письмо с восстановлением пароля не приходит, тогда приходится изучить записи DNS методом перебора, выяснять перечень активных поддоменов, клонировать DNS и переключить трафик посетителей сайта на этот новый DNS-сервер, от которого доступ есть и у заказчика и у нас.

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

Многих клиентов с самого начала сотрудничества волнует вопрос передачи доступа к информации и системам. Обычно для полноценной поддержки требуется полный контроль, как минимум, над серверами и хостингом. Как правило, это root доступы SSH к операционным системам, доступы в личные кабинеты хостинга. Мы высоко ценим вопросы безопасности и разделения прав доступа и при необходимости подписываем NDA. Но прием проекта на техподдержку по администрированию зачастую требует от клиента предоставления ряда доступов к инфраструктуре, которые выходят за рамки одного проекта, передаваемого на обслуживание. Как пример: доступы к регистраторам доменных имен, доступы в личный кабинет хостинга, доступы к инфраструктуре виртуализации, доступы в защищенную сеть заказчика. Если у заказчика несколько проектов и он не хочет передавать нам их все на поддержку или требуются доступы к защищенным участкам сети заказчика, это создает проблемы. Нами наработан опыт сотрудничества с заказчиком по таким случаям, и если мы не получаем требуемый доступ, то применяем метод «remote hands». Его суть в том, чтобы максимально полно проконсультировать сотрудников заказчика, что нужно сделать, буквально какие кнопки нужно нажать и какие команды ввести, для выполнения требуемых действий. При этом заказчик и его служба безопасности полностью и прозрачно участвует в процессе и могут принять решение — безопасны ли для них эти действия.

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

3. Аудит

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

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

По результатам аудита нередко оказывается, что проекту требуется настройка ПО или изменение аппаратного обеспечения серверов и сопутствующего серверного оборудования.

Проводится аудит безопасности, он также часто выявляет уязвимости ПО. Это очень важный момент, т.к. проекты зачастую публичные и ежесекундно подвергаются посягательствам со стороны хакеров. Часто выясняется, что у проекта или вообще нет резервных копий, или они не полны. 

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

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

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

4. Отчет об аудите

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

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

5. План действий

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

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

А что потом?

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