Поддержка высоконагруженного проекта07.02.2017 22:33

Евгений Потапов (eapotapov)

Доклад будет про то, что делать с проектом после того, как мы его запустили. Вы спланировали архитектуру проекта, вы продумали, как у него будет работать инфраструктура, продумали, как будете балансировать нагрузку, наконец, его запустили. Что делать дальше? Как поддерживать, как сделать так, чтобы проект продолжал работать, и как сделать так, чтобы ничего, в конце концов, не упало?

Для начала немного о себе. Я из компании «ITSumma», наша компания занимается круглосуточной поддержкой и администрированием вебсайтов. Сейчас у нас работает 50 человек, мы основаны в 2008 году, мы поддерживаем больше 1000 серверов, которые каждый день посещает больше 100 млн. человек.

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

Если говорить о поддержке, из чего она состоит? На мой взгляд, она состоит из трех компонентов:

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

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

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

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

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

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

Проблемы на сервере. Самые простые штуки, которые можно там мониторить, это:

статистика по нагрузке на центральный процессор, где мы смотрим на нагрузку на сам процессор и на косвенные показатели по этой нагрузке — load average — скользящая средняя;
статистика по нагрузке на дисковую подсистему;
статистика использования оперативной памяти и swap.

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

Статистика по серверному софту. Ставим оповещения на падения и всплески числа запросов на сервер. Смотрим внешне на проверки по доступности сайта, причем, если мы устанавливаем внешние проверки на доступность, мы должны проверять не только время ответа страниц и кода ответа, но часто случаются ошибки со стороны разработки, когда вместо http 502, сервер отдает http 200, и страница, вроде бы, выдает ошибку, но для системы мониторинга, для поисковых движков, она продолжает считаться валидной, нормальной страницей, в которой просто написан текст ошибки. Поэтому мы рекомендуем:

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

Оповещения о проблемах на уровне приложения. В первую очередь, следует замониторить число ошибок уровня приложения. Да, есть логи, в которые можно посмотреть, но чаще всего на любых проектах, рано или поздно, в стремлении делать какие-то новые фичи, не хватает времени разобраться с тем количеством нотификационных сообщений, о которых приходит информация от приложения. Вместо того чтобы разбираться с этим потоком, один из простых методов — это наблюдать за количеством таких сообщений в минуту. Т.е. мы смотрим, что у нас где-то 100–200 таких сообщений в минуту, потом в результате какой-то очередной выкладки у нас резко подскакивает это число до 2000–3000, т.е. нас не интересует отдельная строка, нас интересует общее большое число по этим оповещениям.

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

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

Есть такая прикольная штука, которую почему-то очень редко делают (что удивительно) — это мониторинг бизнес-логики.

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

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

Другая штука, которую мы не совсем правильно видим в мониторинге, — это когда оповещения устанавливаются на критические показатели уже близкие к страшной-страшной беде. Люди ставят оповещения на загрузку процессоров на 99% в течение 5–10 минут. Тот момент, когда к вам приходят такие данные, вы технически сделать практически ничего не можете, т.е. вы уже имеете у себя загруженный сервер, вы уже имеете у себя упавшее приложение и вам надо в аврале, в пожаре решить, что же с этим делать. На старте проекта, после какого-то времени запуска, и после того, как вы сможете проанализировать, какой характер у вашего трафика, вы можете понять характер нагрузки. Например, если у вас процессор загружен на 30%, не нужно ставить оповещение на 90%, не нужно ставить оповещение на 99%, нужно для себя выбрать какие-то ключевые точки, на которых вам нужно принимать новые решения. Т.е. алерт на 50%, и вы понимаете, что у вас обычно была нагрузка в 30%, к которой вы привыкли, а теперь 50%. Это не страшно с точки зрения работы сервера, но вам пора подумать о том, каким будет дальнейший рост, и когда вы дойдете до 70% и т.д. В таких случаях вы получите запас времени, когда вы сможете решить, что же делать, можете ли вы с этим еще жить, или уже пора думать, как менять архитектуру, может, докупить нового железа, может, надо что-нибудь сделать с кодом, если в последнее время что-то случилось, из-за чего он стал отвечать дольше и т.д.

Мониторинг как система анализа. Если мы до этого говорили, что мониторинг — это система оповещения, то выбирая систему мониторинга, мы должны понять, что это не только система оповещения, но это и система анализа, которая:

a) должна хранить максимально возможное количество данных;
b) должна дать возможность быстро выбрать эти данные за нужный период;
c) уметь их быстро отобразить в нужном нам виде.

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

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

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

В докладе на RootConf«е мы с коллегой рассматривали примеры тех систем мониторинга, которые доступны в настоящее время, и если говорить о том, что можно использовать, то более-менее ready это классический Zabbix и Graphite. Но что интересно, к чему я говорю про третью часть с быстрой выборкой большого диапазона исторических данных, — у нас, если смотреть по нашим клиентам, где-то порядка 70% сидит на Zabbix«е и около 20% сидит на Graphite, и любая нода с Graphite«ом занимается тем, что практически забита на 100% по процессору. Т.е. система хороша для записи данных, она хороша для их отображения, но регулярно возникают проблемы с тем, что мониторинг просто не может отрисовать то, что от него хотят. Т.е. система должна сделать это быстро, а получить это быстро нельзя.

Дополнительная штука, если вы будете выбирать систему мониторинга, очень была бы полезна — это сложная агрегация метрик. Чаще всего какие-то из метрик на проекте могут быть относительно с шумом, этот шум необходимо каким-то образом минимизировать, получить скользящую среднюю, посмотреть по запросам перцентиль, в какое количество времени выполнилось 99% запросов, сгруппировать запросы по минимальному в течение времени и т.д.

Кроме этого, мониторинг нужно представлять себе как систему для принятия решений.

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

a) понять, как авария случилась, и что сделать такого, чтобы это не повторилось;
b) посмотреть на то, как система будет развиваться в будущем;
c) посмотреть на то, как сделать так, чтобы избежать ошибок, которые уже были.

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

Сложный сбор данных. Я бы сейчас обратил внимание на Graphite, но вам придется сильно помучиться, решая, как хранить там данные. Если у вас очень сложная система, если у вас очень сложные данные, можно подумать о том, чтобы сделать свою систему или сильно кастомизировать open source, но нужно понимать, что это очень-очень большой вклад в инвестиции в развитие этой системы.

Мы используем собственную систему, потому что у нас исторически сложилось, что инфраструктура очень гетерогенная, у нас высокие требования к тому, как она должна поддерживаться, и как должны скалироваться проблемы внутри компании. Мы разработку этой штуковины ведем с 2008 года. У нас есть два разработчика, которые этим постоянно занимаются, и у нас есть очень-очень много пожеланий от админов, как эту штуку дальше изменять. Единственная причина, по которой мы используем эту штуку, а не Graphite или Zabbix, это то, что мы понимаем, чего мы можем получить от системы мониторинга. Мы понимаем, как ее доработать, и можем мы это сделать или не можем этого сделать. Но и, кроме всего, нужно понять, что к системе мониторинга вы привыкаете, и в тот момент, когда вы ее выбрали, чем дольше вы используете одну и ту же систему, тем дольше после этого вам не захочется с нее слезть, даже если вы ей не довольны.

Переходим ко второй части. Поговорим о резервном копировании и резервировании.

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

Резервное копирование создает нагрузку на сервер.
Для вашего проекта может сыграть большую роль регулярность снятия резервных копий. Например, у вас постоянно огромное количество пользователей совершают какое-то действие, пусть это сервис, где люди за деньги обрабатывают фотографии. Если у вас бэкапы делаются раз в день, данные пропали, и вы восстановились из 20-тичасовой давности, вы все равно получите огромное количество проблем, связанных с тем, что пользователи будут говорить: «OK, а где мои данные за последние 20 часов?».
Нужно понимать, что время восстановления из резервной копии также играет роль. Т.е. вы можете делать дамп, который делается быстро, но этот дамп в некоторых случаях может выливаться очень долго.

Процесс снятия резервной копии:

Сам по себе тяжелая процедура.
Резервные копии из-за этого лучше всего создавать c резервных машин, не создавая нагрузку на продакшиновых машинах.
Нужно понимать то, что нужно резервировать. Классическая штука — бэкапим часто базу. «А вот у нас очень много статики, которую генерирует пользователи, ее мы лучше будем генерировать раз в день». Но какой смысл раз в несколько часов бэкапить базу, если когда вы из нее восстановитесь, у вас не будет статики, и пользователи точно также будут недовольны, как и раньше? Т.е. они уедут, условно говоря. У вас сервис второй ВКонтактик, вы дропнули базу, у вас упал сервер, и вы подняли из резервной копии с базой, у вас есть ссылки на фотографии, но нет самих фотографий…
Классическая штука. Бэкап без регулярной процедуры восстановления — не бэкап. Очень часто мы видим, когда люди организовали бэкап, они его загружают, и они считают, что этого достаточно. В четырех из десяти случаев из резервной копии, которая есть, восстановиться без проверок, оказывается, нельзя. Должна быть в организации создана регулярная процедура восстановления, регулярный план учений, по которым вы в заданную дату начинаете восстанавливаться из резервной копии, проверять, за сколько вы можете это сделать, насколько актуальны будут ваши данные, и насколько будет работоспособен сайт после восстановления из резервной копии.

Резервные копии баз.

Используем slave-сервер только как резервную копию на случай аварии мастер-сервера. Есть классическая история падения Сбербанка несколько лет назад, когда они использовали slave-сервер как резервную копию и больше ничего с ним не делали. Т.е. не было бэкапов, был лишь slave, а нужно понимать, что slave принимает все запросы, и если пришел человек на мастер-сервер и сказал: «Удалить все из мастер-сервера», slave получит точно такую же команду.

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

Hot-backup-службы для регулярного внешнего резервного копирования. Т.е. у нас есть slave для защиты от аварии, и hot-backup для защиты от человеческого фактора.

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

Нельзя хранить копию в том же месте, где вы ожидаете, что может случиться авария, потому что когда целиком упадет дата-цент в Hetzner«е, вы не сможете восстановиться, если он упадет на несколько дней. Все эти несколько дней, вы, даже обладая правильным бэкапом, даже делая правильные процедуры, будете просто ждать, пока не поднимется хостинг. При этом нужно понимать, что аварии в хостингах — это не всегда вопрос 10, 15, 20-ти минут. У Amazon за последние пять лет было четыре аварии, самая длинная из которых длилась 48 часов, следующая длилась 24 часа, следующая длилась 16 часов, следующая длилась порядка 10-ти часов. Они каждый раз говорили, что «мы жутко извиняемся, вернем вам деньги, которые стоил хостинг в это время», но понятно, что это не сравнимо с теми потерями, которые были на деле. Поэтому хранить бэкапы идеально еще в другом месте, откуда вы знаете, что если эта площадка упадет, вы сможете восстановиться.

Контент. Сложная-сложная тема, особенно, если у вас его много. Если у вас его не много, делаем регулярнные Rsync, делаем снэпшоты. Если у вас его много, то лучше всего эту штуку реализовать сразу на уровне приложения. Пусть у вас заливается фотография, какой-то файл, который заливается или обрабатывается пользователем. После выдачи данных контента пользователю сделайте, чтобы в данный момент этот файл дублировался на резервную копию. Вам не нужно будет тогда регулярно копировать всю пачку изменений раз в день, раз в час и т.д. Одно действие, но простое, оно делается незаметно для пользователя, потому что контент ему уже отдается. Просто фоном файл переливается в другое место, в другую площадку, которая не зависима от основной.

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

Есть резервное копирование, есть резервирование, это разные вещи.

Выбор площадки для резервирования.

Резервная площадка не должна быть связана с текущим дата-центром. Мы очень часто видим, когда к основному серверу берется резервный сервер в том же месте, т.е., условно говоря, тот же самый Hetzner, где у вас есть одна машина в стойке, и вторая машина в стойке выступает как резерв. Да, она защитит от аварий самого сервера, но она никак не защитит от аварий во всем дата-центре в целом. Если мы выбираем резервную площадку к основной, чаще всего люди хотят сделать так, чтобы она была дешевле, потому что она не получает трафик. Нужно понимать, что после переключения на резервную, вы можете оказаться в такой ситуации, когда вы останетесь с ней надолго. И если вы считаете, что на ней можно прожить час, но на ней не получится прожить день или больше, лучше уже подумать о том, стоит ли так делать.

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

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

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

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

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

Подводя итоги.

Slave — это не бэкап.
Бэкап в том же дата-центре — это не бэкап.
Резерв в том же дата-центре — это не резерв.
Бэкап, который не восстанавливали — это не бэкап.
Бэкап без статики — это не бэкап, потому что люди просто будут не знать, что у них с контентом.
Если не хватает места — это не отмазка. Очень часто мы слышим: «Ребята, у нас плохо с бэкапом, у нас сейчас не хватает места, мы решим это через неделю». Буквально на днях, клиенты, которые собирались решить проблему через неделю, потеряли два сервера. Там было дополнительное резервирование, которое мы сделали, которое помогло. Но будет очень обидно, когда вы поймете, что вы неделю думали, когда же у вас найдется время, чтобы сделать бэкап и взять сервер в Hetzner«е за 60 евро с 2 Тб дисков, вместо этого вы ничего не сделали и потеряли данные, которые стоят гораздо дороже.
«Я решу про бэкап на днях» — это фраза, которая ведет к потерянным данным. Один шаг до потерянных данных.

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

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

Они должны обладать потрясающей стрессоустойчивостью, потому что иногда, особенно на запуске проекта, такие смс приходят каждый день первые полгода. Чаще всего на старте это разработчики с задатками админа, которые и знают, как работает код, и могут поправить, и знают, как подконфигурить сервер, чтобы оно заработало. И должны быть экстраверты, потому что если вы с ними работаете или вам нужно с ними взаимодействовать, очень неприятно ждать в течение 30 минут или часа, пока человек разберется, но он при этом об этом не говорит. Т.е. ты говоришь: «Вася, как дела?». А Вася не отвечает. Лучше, если хоть кто-то в этой команде есть экстравертный, который скажет: «Ребят, вот там так-так и так, мы делаем это все, и сейчас все исправим».

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

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

Как работать на поддержке такой штуки на запуске вашего проекта. На старте, это будут просто СМС-ки ключевым людям и телефонные звонки людям, которые не спят и смотрят постоянно, как это работает. Затем, это, возможно, дежурства людей внутри команды, дополнительных людей. Для старта подходит двое через двое по 12 часов. Но долго люди не продержатся, просто потому что те, кто будут работать в ночную смену, у них, вполне возможно, есть жены, дети, семьи. И когда они отработают с 8-ми вечера до 8-ми утра (это я говорю из жизненного опыта), в 10–11 утра их эти же самые жены, дети, семьи, друзья, начнут звонить и говорить: «Вася, пойдем дальше». И очень тяжело в этот момен