44  /  96

Эксплуатация проекта

Просмотров: 1265 (Статистика ведётся с 06.02.2017)

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Содержание главы:

1
Курсы разработаны в компании «1С-Битрикс»

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