Как атака БПЛА на Яндекс чуть не уничтожила мою инди-игру

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

Воскресенье началось не по плану

Утром 11 октября я, как обычно, решила проверить, как поживает моя игра. У меня есть привычка начинать день с административной панели: посмотреть, сколько человек играло вчера, сколько появилось новых пользователей, были ли внутриигровые покупки и не написал ли кто-нибудь ночью в поддержку. Для небольшого инди-проекта такая статистика — своеобразный утренний ритуал, позволяющий убедиться, что всё работает, а твои усилия по развитию игры не проходят даром.

Но в то воскресенье привычный ритуал неожиданно прервался. Административная панель попросту не открывалась.

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

Попробовав открыть саму игру и убедившись, что она тоже недоступна, я отправилась в личный кабинет своего хостинг-провайдера Amvera. Там меня ожидало сообщение о том, что из-за атаки БПЛА на инфраструктуру Яндекса сервисы провайдера временно недоступны.

Вот тут стало понятно, что обычным откатом последнего коммита проблему не решить.

Дело в том, что я разрабатываю многопользовательскую карточную стратегию PanzerShrek, посвящённую танковым сражениям Второй мировой войны. Игроки собирают собственные колоды боевой техники, сражаются друг с другом, участвуют в исторических кампаниях, развивают аккаунты и пополняют коллекции. Игра доступна как в браузере, так и на Android (кстати, опубликовать игру в Play Market из России было отдельный квестом), а поскольку значительная часть игровой логики завязана на взаимодействии с сервером, его недоступность фактически означает остановку всего проекта.

Причём 11 октября было воскресенье, а выходные традиционно обеспечивают мне хорошую посещаемость. У PanzerShrek довольно взрослая аудитория, преимущественно люди старше 30 лет, которым удобнее играть в свободное от работы время. Поэтому отключение серверов произошло в один из самых неподходящих моментов.

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

Почему я выбрала Amvera и какое отношение здесь имеет Яндекс

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

Поэтому я стала искать подходящий российский хостинг и в итоге остановилась на Amvera.

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

Но самым приятным оказался процесс развёртывания приложения.

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

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

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

В начале октября появились сообщения об атаках БПЛА на дата-центры Яндекса. Сначала пострадала инфраструктура в Сасове, затем появились новости о проблемах с другими объектами. Однако моя игра продолжала работать, и я даже мысленно поздравила себя с выбором хостинга, который, как мне тогда казалось, не имел отношения к инфраструктуре Яндекса.

Как выяснилось позднее, зависимость всё-таки существовала, хотя я о ней совершенно не подозревала.

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

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

Когда остаётся только ждать

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

Оставалось следить за сообщениями Amvera и ждать, когда инженерам удастся восстановить работу сервисов.

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

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

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

Конечно, я знала, что резервные копии существуют. Более того, на моём тарифе Amvera предусмотрено автоматическое еженедельное резервное копирование с хранением четырёх последних версий.

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

И, надо признаться, до определённого момента эта логика меня полностью устраивала.

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

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

База данных есть, но пользоваться ею нельзя

Примерно 14 октября доступ к личному кабинету Amvera начал восстанавливаться, и я наконец получила возможность заняться развёртыванием приложения.

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

SQLite сообщала:

database disk image is malformed

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

Но если файл базы оказывается повреждён, восстановление данных может превратиться в весьма увлекательное занятие.

Сначала я скачала резервную копию на локальный компьютер и решила проверить её стандартными средствами SQLite. Выполнила проверку целостности:

PRAGMA integrity_check;

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

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

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

На момент аварии в игре было около 500 зарегистрированных пользователей и примерно 2000 гостевых аккаунтов. Гостевые аккаунты — отдельная особенность моей игры: многие пользователи предпочитают сначала познакомиться с ней без полноценной регистрации, поэтому их количество довольно велико.

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

Разумеется, такой результат меня совершенно не устраивал. Я обратилась в техническую поддержку Amvera, объяснила ситуацию и попросила попробовать восстановить данные на стороне провайдера. Сотрудники согласились помочь, и примерно через сутки мне предоставили обработанную резервную копию.

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

Получалось, что сервер постепенно возвращался к жизни, исходный код приложения никуда не исчез, но самая важная часть проекта — информация о пользователях — оказалась серьёзно повреждена.

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

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

Как старый файл в папке «Загрузки» спас аккаунты

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

С тех пор он так и лежал среди прочего содержимого папки «Загрузки».

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

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

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

Это был огромный шаг вперёд по сравнению с первоначальными 114–145 аккаунтами, которые удавалось извлечь из повреждённых резервных копий.

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

При этом мне очень повезло с ещё одной категорией информации: история транзакций внутриигровых покупок сохранилась в полном объёме. Благодаря этому я могла разобраться с ранее совершёнными платежами и восстановить оплаченные приобретения пользователей.

Именно тогда я в полной мере оценила значение того самого случайно скачанного августовского файла.

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

Думаю, более наглядную демонстрацию необходимости независимого резервного копирования сложно придумать.

Решение, которое не хочется принимать разработчику

Когда стало понятно, что полностью восстановить игровой прогресс не получится, передо мной возник довольно неприятный вопрос: что делать дальше?

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

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

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

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

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

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

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

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

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

Сервер заработал. Теперь нужно починить всё остальное

Восстановление приложения оказалось не просто запуском нового контейнера с прежним кодом.

Поскольку IP-адрес сервера изменился, мне пришлось обновлять DNS-записи у регистратора доменного имени и проверять, что клиентские приложения обращаются по правильному адресу. Затем нужно было убедиться, что корректно работают авторизация, игровые соединения, административная панель и прочие серверные механизмы.

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

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

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

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

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

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

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

Я боялась, что игроки не вернутся

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

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

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

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

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

Но реакция игроков оказалась совершенно неожиданной.

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

Меня это очень удивило и одновременно невероятно поддержало.

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

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

И самое удивительное произошло после восстановления серверов.

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

Более того, пользователи снова начали совершать внутриигровые покупки, то есть поддерживали проект не только своим присутствием, но и деньгами.

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

Разумеется, несколько дней простоя всё равно обошлись проекту довольно дорого. За это время я могла бы заниматься новыми механиками, выпускать обновления, тестировать игровые режимы и привлекать дополнительных пользователей. Вместо этого пришлось восстанавливать данные и исправлять последствия аварии.

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

Как я решила превратить аварию в часть истории игры

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

И когда я размышляла о том, как поддержать игроков после произошедшего, мне вспомнилась история восстановления Горьковского автомобильного завода после немецких бомбардировок летом 1943 года.

ГАЗ тогда подвергся серии разрушительных авиационных ударов, в результате которых серьёзно пострадали производственные корпуса, оборудование и инфраструктура предприятия. Тем не менее завод удалось восстановить, а производство продолжилось.

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

Поэтому следующую историческую кампанию PanzerShrek я решила посвятить именно Горьковскому автомобильному заводу и его восстановлению после бомбардировок.

Кроме того, мне захотелось как-то отметить игроков, которые остались с проектом в этот непростой период.

В результате я придумала специальный памятный набор, который будет доступен исключительно тем, кто был зарегистрирован в игре во время аварии. В него войдут уникальная рубашка для игровых карт и три эксклюзивные карты: американский ударный беспилотник, немецкий разведывательный БПЛА и советская зенитная установка на базе грузовика ГАЗ-АА.

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

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

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

Чему меня научила эта история

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

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

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

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

Главный вывод оказался довольно банальным: наличие резервной копии совершенно не гарантирует, что из неё удастся восстановить работоспособную систему.

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

В случае SQLite есть ещё один важный нюанс. Поскольку база данных представляет собой файл, возникает естественное желание просто регулярно копировать его в другое место. Однако если делать это во время активной работы приложения, особенно при использовании режима WAL, можно получить несогласованную копию. Поэтому резервирование нужно организовывать с использованием штатных механизмов SQLite, например Online Backup API, а затем проверять полученный результат.

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

Собственно, именно это и продемонстрировал забытый августовский файл.

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

Тем не менее для небольшого инди-проекта даже регулярная выгрузка базы на отдельный носитель будет большим шагом вперёд по сравнению с полным отсутствием независимого резервирования.

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

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

И наконец, я стала гораздо внимательнее относиться к зависимости от облачных сервисов.

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

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

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

Поэтому фраза «ваши бэкапы — ваши проблемы» после этой истории приобрела для меня совершенно практический смысл.

Вместо заключения

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

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

И всё-таки самое интересное открытие оказалось связано вовсе не с SQLite, особенностями резервного копирования или зависимостью облачных платформ от сторонней инфраструктуры.

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

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

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

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

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

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

Каким бы хорошим ни был код, насколько продуманной ни казалась бы архитектура, рано или поздно всё равно произойдёт что-нибудь непредвиденное. Главное — суметь разобраться с последствиями, сделать выводы и не потерять желание развивать собственный продукт.

По крайней мере, именно этому меня научила первая большая авария PanzerShrek.

А ещё теперь я регулярно вспоминаю о резервном копировании. И, знаете, старый августовский бэкап из папки «Загрузки» я пока на всякий случай удалять не собираюсь.

P. S. Интересно, сталкивались ли вы с ситуациями, когда резервные копии формально существовали, но восстановить из них данные не удавалось? Особенно интересен опыт небольших проектов, где нет отдельного DevOps-инженера и полноценной команды администраторов. Как вы организуете резервное копирование и насколько часто проверяете возможность реального восстановления?