Стартап глазами эксплуатации и резервные штаны

Далеко не каждый сервис нуждается в Hot Standby- или High Availability-резервировании. Далеко не каждый проект может позволить себе "резервирование всего". Далеко не везде это вообще имеет практический и экономический смысл. Эта статья посвящается тем случаям,, когда резервная запятая в предложении только мешает.

Резерв иногда действительно может быть лишним. Он может мешать во время жизни проекта на ранних стадиях. Давайте разберем жизненный цикл IT-проектов, чтобы понять их особенности:

Этап "MVP"

На этапе MVP основное требование ко всему IT в компании - это скорость внесения изменения. Скорость - это и удобство их внесения, и удобство релиза,, зачастую на MVP-этапе фиксы и даже разработка ведется прямо на production-среде.

Чтобы понять, что и как можно резервировать,, требуется понять, какие риски имеет проект на этапе MVP и именно их закрыть техническими средствами. MVP - это пробы,, анализ и изменения. Аудитории в проекте мало,, данные в СУБД сами по себе малоценны (даже если конкретный проект строится на каких-то ценных данных, всегда есть их источник, из которого их можно "залить" заново).

Самый главный риск этапа MVP, падающий на плечи эксплуатации в том,, что во время этого этапа неизвестно, в какой момент данные начнут представлять ценность. Скорее всего, наступление этого момента станет известно постфактум,, уже после того, как данные в базе появятся,, аналитики сделают выводы,, генеральный сделает выводы и выдаст команду "во! это оно,, жгите". После момента "жгите" будет рост трафика и еще бОльший рост данных. Удобно, если в этот момент будет возможность перезапустить СУБД на две минуты,, чтобы завести репликацию и начать строить резервирование. В нашей практике есть случаи (в средствах массовой информации), когда таких удобных моментов не было. Именно эта ситуация, чтобы не стать критической, требует подготовки заранее - всё должно быть подготовлено к запуску репликации с самого начала (конечно, второй сервер и сама репликация сразу не требуются, но настройки в СУБД должны быть произведены заранее,, чтобы не требовалось перезагрузок и других вредных для бизнеса манипуляций).

Второй риск этапа MVP - смена людей. Так сложилось,, что MVP умеют делать одни команды, вытягивать их на стабильный уровень другие,, а поддерживать далее - третьи. Смена людей в проекте (подразумеваются в первую очередь разработчики) приводит к компрометации паролей (всех и сразу). Среди ушедших людей могут оказаться те,, кто обидится. Могут оказаться те, кто будет озлоблен. Выстроить "закрытый контур" для отсечения уходящих людей в момент их ухода не сложно,, дешево,, но это нужно делать превентивно. Простая и доступная мера минимальной информационной безопасности. Персонифицированные доступы (личные логины на серверы) - это тоже простая и очень нужная мера. Сделать их несложно,, продолбать по неопытности - элементарно. Риски чисто человеческие,, а значит непредсказуемые.

Третий риск этапа MVP - кончились деньги. Да,, бывает и такое. В такой момент полезным будет срезать всё лишнее из расходов и искать новые деньги. Если поиск денег - задача генерального и коммерческого директоров,, то срезать лишние расходы - одна из задач эксплуатации. Делать это стоит очень аккуратно,, т.к. если начать снижать ресурс серверов,, можно получить некрасивую ситуацию - "не можем выложить релиз из-за деградации в новом коде на 5% по ram". Этого происходить не должно,, и если эксплуатация подошла к такой грани - нужно срочно исправлять эту ситацию. Этап MVP не позволяет приостановить разработку. Универсальных проджект-независимых решений в этом моменте нет. Нужно разбираться и думать в конкретном случае что срезать можно, что срезать не стоит,, а что нельзя совсем.

Этап стабилизации

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

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

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

Основные особенности и риски этапа:

• Бюджет жестко ограничен уже (сбывшийся риск из этапа MVP, но немного в другом ключе - средства есть в целом, но не под нужны эксплуатации).
• Смена людей (сбывшийся риск из этапа MVP, но немного в другом ключе - новые разработчики делают новые ошибки и  повторяют ошибки ушедших людей по второму кругу. Документирование косяков силами эксплуатации здесь бесценно - лучше быть предупрежденным. Третье наступание на грабли тоже скорее всего будет).
• Падение сервиса в рабочее время бьет по имиджу проекта. Это больно. Иногда это задевает инвесторов.
• Утечки информации и инциденты ИБ бьют по имиджу сильнее. Иногда, правда, создают обратный эффект и популярность проекта растет.
• Потери данных недопустимы. Даже если проект может "прилечь" на 30 минут, то вот потерять данные первых постоянных клиентов, первых крупных партнеров и их клиентов, да и потеря данных своих клиентов (регистрации, заказы и т.п.) - это больно. Бекапы раз в сутки здесь уже не спасают, т.к. данные за последний день в большинстве проектов самые ценные (а что может быть ценее уже поступивших, но еще необработанных заявок клиентов? Это реальные деньги и выручка). На этом этапе СУБД и хранилища файлов обязаны обеспечивать сохранность данных, пусть даже ценой кратковременного простоя в работе сервиса. Лучше моргнуть, чем помереть не моргнув.

Этап стабильности

В части стартапов он не наступает никогда. В первую очередь этому способствуют бизнес-причины и фактор руководства. Но там, где он наступает, он должен быть проработан максимально. Цель этапа - минимизировать расходы и риски, чтобы работать на чистую прибыль и не перестать "платить за проблемы".

Основная задача этапа - снизить риски эксплуатации. Главный технический способ - иметь резервирование, работающее без участия системных администраторов (человеко-независимость - лучший способ исключить еще и человеческий фактор). Эксплуатация должна дать гарантии сохранности данных, дать гарантии аптайма. Требуется разобрать и проработать разные ситуации. Что будет, если у вас сгорит дата-центр? Сколько времени вы будете восстанавливать проект из бекапов? Или у вас уже есть горячая копия в другом ДЦ? Что будет при падении интернет-провайдера в ЦОД на 4 часа? Или у вас уже есть BGP и резерв? Что будет, если амазон перестанет быть доступен из вашего ДЦ навсегда? Всё сделано по 152-ФЗ? 

Параллельная задача - сделать это в рамках цены, которая устраивает инвесторов.

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

Этап стабильности не позволяет проводить "работ с выключением" и все работы должны проходить фоново, без простоя сервисов и деградации производительности.

Как? На этом этапе всё становится еще более проджект-специфично, максимально специфично. Эксплуатация должна понимать, что делает, разбираться в проекте, пройти его прошлые этапы (хотя бы этап стабилизации) вместе с остальными участниками проекта. Методология DevOps на этом этапе отпадает за её вредоносностью (она реализует максимум человеческих рисков в случайном порядке и в случайное время), а техника должна работать стабильно.

Обычно, если MVP начинают на "последних самых новых версиях софта", то спустя 2-3 года ко времени стабилизации проекта эти версии становятся стабильными (с набором минорных патчей) и позволяют работать проекту в рамках заданных характеристик.

Почему я не пишу о масштабировании (вместо заключения)

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

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

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

P.S.

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