Кто будет заниматься эксплуатацией?

Варианта решения этого вопроса два: студия или сам клиент.

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

Вариант передачи проекта на эксплуатацию клиенту кажется предпочтительным для средних и крупных проектов. Действительно, в крупных компаниях работают, как правило, сильные системные администраторы, и кажется логичным довериться им. Но использование системных администраторов клиентов имеет свои сложности. Высококвалифицированный администратор может не знать не только Bitrix Framework, но и вообще не знать, что такое php-разработка и стек LAMP-технологий. Они могут не знать, как создать, настроить и сопровождать систему мониторинга и анализа. Это рождает свои проблемы: будут говорить, что студия написала "говнокод", мол надо переделать. Эти риски есть, и их надо учитывать.

Если проект находится на постоянной доработке студией, то возникает ещё одна проблема при эксплуатации проекта клиентом: внесение обновлений по собственно проекту, обновления Bitrix Framework и обновления серверного программного обеспечения. Необходимо выстраивать процесс выкладки изменений на сервере с тестового на боевой, процесс обновления ПО. Соответственно, встают проблемы взаимодействия с IT-службой клиента.

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

Большинство веб-студий не обладает, как правило, штатом квалифицированных системных администраторов. Имеющиеся администраторы знают понятие "хостинг", могут с правами root'а выгрузить проект на хостинг с настройками по умолчанию. На маленьких проектах это работает. Но на средних и больших проектах нужна профессиональная эксплуатация проекта: нужно разбираться в "железе", в Unix'ах. Крайне мало людей, которые могут одинаково хорошо писать код и разбираться в железе и ОС Unix.

В этом плане есть смысл максимально перенести низкоуровневое администрирование на хостера или облачного провайдера. Самое простое решение этой задачи: уйти в облако. Большая часть задач, которые нужно решать при эксплуатации проекта, уже решена облачным провайдером. Нет проблем с мониторингом сервера, нет работ по обслуживанию сервера (менять диски, мониторить температуру сервера и так далее). В дополнение предоставляются возможности, позволяющие полностью сосредоточиться на выполнении бизнес-задач: лёгкое выполнение бекапов, легко создавать репликацию, можно легко переносить машины и запускать проект на любых мощностях. В этих условиях качество услуг студии возрастает, сроки выпуска легче соблюдать и нет необходимости заниматься сложными настройками Linux'а.

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

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

  Техническое задание на эксплуатацию

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

• Количество хитов в сутки.
• Скорость загрузки главной страницы при указанном количестве хитов.
• Скорость загрузки критичных разделов.
• Среднее время загрузки всех страниц в сутки.
• Процент страниц с временем загрузки более n сек. (Исключения, которые допустимы.)
• Допустимый процент ошибок.
• Допустимое время простоя и когда и в каком масштабе оно допустимо. Например, SLA Amazon'а на его виртуальной машине - 99.85%. Что означает 13 часов простоя за год. Согласен ли Клиент на такой простой и при каких условиях? (Можно "лежать" полдня один раз за год, а можно по 2 минуты, но каждый день.)

Крайне редко заказчик может выдать такие цифры, тем более не ошибившись. Задача веб-студии – помочь ему в определении этих значений.

Надо также объяснить заказчику, зачем ему нужно определиться в этих цифрах:

• Лояльность клиентов. Если сайт часто "лежит", то клиент будет склонен к смене сервиса. Замедление загрузки страницы на 1 секунду снижает конверсию на 7%, а количество просмотров - на 11%.

  

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

Отдельно нужно обговорить условия проведения технических работ на сайте. Технические работы должны проходить незаметно для клиентов:

• Сервисные работы;
• Замена оборудования;
• Обновления системного ПО;
• Обновления приложений.

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

  Основные задачи в процессе эксплуатации

• Обеспечение производительности
• Обеспечение отказоустойчивости
• Обеспечение безопасности

Большая часть задач решается за счёт постоянного мониторинга.

Дополнительно