Фактор времени – своевременность выполнения заказов, работ, договоренностей – является важным в бизнесе. Клиенты и партнеры ожидают предсказуемых временных затрат при сотрудничестве. В традиционном бизнесе на это влияет работа сотрудников, действия поставщиков, географическое расположение компании, состояние оборудования и многое другое. Локализовать и проконтролировать всё это – сложная задача.

Несколько понятнее все обстоит в сфере IT. Значительную часть процессов можно автоматизировать и поручить программе или скрипту. Еще лучше, если продукт реализован как веб-сервис – основное занятие сводится к поддержке работоспособности и развитию продукта.

Один из основных продуктов нашей фирмы является именно веб-сервисом. Началось все с реализации идеи двух человек, затем компания выросла: PM (он же программист по вэбу), программист по базе данных, системный администратор (с небольшим опытом разработчика), тестировщик и еще два человека, занятых продажами и SEO. Система реализована в виде веб-интерфейса и связанной с ним базы данных. Использование сервиса предполагает ввод и вывод денег, которые хранятся в «виртуальной валюте». Для безопасности, веб-сервер и база данных развернуты у себя, на своих серверах.

Так как сервис связан с деньгами, важен уровень доверия пользователя к системе. В первую очередь, это вопрос безопасности и защиты системы от взлома. Однако, обычному клиенту (особенно не разбирающемуся в тонкостях IT, защищенных протоколах и шифровании) сложно оценить уровень безопасности системы. Если негативной ситуации (взлома) не произошло, то и работы не видно.

Более явной для клиента является доступность системы: если пользователь перевел на виртуальный счет определенную сумму, а затем не может несколько раз зайти на сайт – доверие к системе подорвано, и клиент, вероятно, потерян (иногда и несколько сразу – негатив распространяется быстро). И привлеченные большим трудом пользователи, натыкаясь на ошибку вместо главной страницы сайта, вряд ли тоже вернутся обратно.

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

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

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

Однажды спокойствию настал конец. В ночь с пятницы на субботу начали пользователи испытывать проблемы доступа к главной станице сайта, зачастую их встречала ошибка 503. Проблема была несложная, но, как и следует, в ночь пятницы админ недоступен, а потому SMS осталось непрочитанным. И все же проблема была решена относительно безболезненно. Разработчик тоже получил SMS, и смог дозвониться и разбудить администратора, и уже через 3 часа проблема была решена. Общий «простой» составил 5 часов.

В понедельник последовал разбор полетов по произошедшему. Анализ данных по посещаемости сайта показал неприятную картину – в «проблемную» пятницу посещаемость снизилась на треть по сравнению с прошлой, но еще более неприятными были значительные падения в субботу и воскресенье, несмотря на отсутствие технических проблем в эти дни, посещаемость снизилась на 15%.

Это усилило понимание необходимости круглосуточного мониторинга. С точки зрения софта выбрали Zabbix, установить и настроить который предстояло системному администратору. Ушло на это около недели – остальные задачи никуда не девались, и все делалось параллельно. Оставался организационный вопрос – кто именно будет мониторить?

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

Найм дополнительных сотрудников для мониторинга

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

Оба варианта не работали. Концентрировать усилия и средства на них не было возможности. Но необходимость в мониторинге никуда не делась. Это одна из проблем роста – возникает потребность, которую реализовать своими силами не удается. В качестве решения пришли к outsource.

При переходе возникали сомнения, основное из них – сохранность и конфиденциальность информации, которая становится доступна кому-то еще и качество обслуживания, не станет ли, наоборот, хуже? Но это скорее вопрос поиска ответственного исполнителя и подписания NDA.

Итак, перешли, с технической стороны это оказалось несложно. Через месяц мы решили проверить, как идут дела – проверив логи на серверах. Результатами довольны – за месяц было три серьезных сбоя, которые потенциально могли бы опять «положить» сервера, но проблемы партнеры решали в течение получаса. При этом все сбои случались в промежутке от часа ночи до четырех утра – сказывался постепенный географический рост продукта.

Работа нашего системного администратора изменилась и стала более спокойной. Не отвлекаясь на мониторинг, он сконцентрировался на DevOps. Мы сосредоточили усилия, и разработка ускорилась. Получилось реализовать то, что давно откладывали, спасибо нашему партеру.

Проблемы роста стартапа — мониторинг