Centered Responsive Wave Button
«Сбой системы» – причины, этапы и уроки сбоя в Senler в июле 2025.

О доверии в цифровую эпоху

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

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

С 12:45 по московскому времени четверга, 24 июля, до 15:40 пятницы, 25 июля, наш сервис был недоступен. Больше суток. В мире, где цифровые сервисы стали продолжением наших рабочих рук, это вечность. Мы понимаем беспокойство, фрустрацию и упущенные возможности, которые принесло это время. В разгар этого шторма мы готовились к волне закономерного недовольства.

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

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

12:45: Внезапная тишина

Кризис пришёл не постепенно. Он не предупреждал о себе медленной деградацией сервиса или чередой мелких ошибок, которые мы могли бы пропустить. В 12:45 в четверг кто-то словно щелкнул гигантским рубильником. Все погасло. Мгновенно. Мы узнали о проблеме не раньше и не позже вас, а в тот же самый момент.

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

Это означало, что решать ее нужно было на всех уровнях одновременно: техническом, коммуникационном и стратегическом. Присутствие основателей гарантировало, что мы можем принимать любые, даже самые сложные и дорогостоящие решения, без бюрократических проволочек. Довольно быстро наша инженерная команда локализовала “эпицентр землетрясения”. Проблема находилась не внутри нашего кода или конфигураций, а на сетевом уровне у нашего основного поставщика облачных ресурсов. И здесь начинается та часть истории, где мы вынуждены быть менее конкретными, чем нам хотелось бы. Сухие формулировки договоров о неразглашении (NDA) не позволяют нам раскрыть технические детали инцидента на стороне партнера. Но они не мешают нам рассказать о том, как мы действовали в условиях этой неопределенности, и о тех выводах, которые мы сделали о самой природе зависимости от внешних поставщиков.

Битва на трех «фронтах»

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

Мы сознательно выбрали путь максимальной открытости. И именно эта стратегия, как мы теперь понимаем, стала причиной той огромной поддержки, которая помогла нам выстоять. Вы видели, что мы не прячемся, что мы рядом и боремся. В современном мире отношения с сообществом — это не «мягкие навыки», это часть критической инфраструктуры устойчивости бизнеса. Диалог с Голиафом: гигант отвечает, но от этого не проще.

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

Мы часами общались с сотрудниками поддержки, которые действовали по скриптам, выдавая стандартные фразы: «Мы работаем над проблемой, ожидайте». Это был тот самый опыт общения с «бездушной» корпоративной машиной, который знаком каждому, кто хоть раз пытался решить свою проблему с крупной компанией. Это обескуражило, но не парализовало нашу работу. Ключевым решением здесь было не биться головой о стену, а принять эту медленную скорость реакции как базовый сценарий. Мы сказали себе: «Хорошо, допустим, помощь от них придет нескоро. Что мы можем сделать сами прямо сейчас?» Этот сдвиг в мышлении позволил нам перенаправить энергию с бесплодного ожидания на активные действия. «Строительство ковчега»: запуск плана восстановления

«Третий фронт», самый ресурсоемкий, был запущен практически одновременно с первыми двумя. Это был наш план «Б» — полное аварийное восстановление на мощностях резервного поставщика облачных услуг. Здесь проявилась важность еще одного нашего принципа: мы с самого начала включили представителей этого резервного партнера в нашу кризисную команду. Это были не просто поставщики серверов; это были партнеры, готовые разговаривать с нами на равных, вникать в суть проблемы и действовать проактивно. Они стали частью нашей команды, и это изменило все. Этот фронт был нашей страховкой, нашим «ковчегом», который мы начали строить, не дожидаясь, “пока закончится потоп”.

Недостатки, честность и новое партнерство

Процесс восстановления никогда не бывает гладким. Это грязная, сложная работа под огромным давлением, и именно здесь на свет выходят все скрытые недостатки и упущения. Мы считаем, что честно рассказать о них — единственный способ доказать нашу приверженность реальным улучшениям. Первый удар мы получили, когда начали разворачивать резервные копии. Выяснилось, что самая последняя резервная копия нашей основной базы данных не была создана. Причина оказалась до боли знакомой многим растущим проектам: наша база данных росла так быстро, что «окно» для ее полного резервного копирования постоянно увеличивалось и в этот раз просто не успело завершиться до сбоя. Это означало, что последняя доступная нам полная копия была сделана 23 июля. Потенциальная потеря данных — почти сутки. Второй неприятный сюрприз ждал нас, когда мы попытались получить доступ к нашему коду для развертывания на новой площадке.
Наш репозиторий GitLab, содержащий всю кодовую базу, находился в той же самой недоступной инфраструктуре основного провайдера. Классическая ошибка - «все яйца в одной корзине». Это был мощный удар, который показал нам слепое пятно в нашей архитектуре. Нам пришлось сначала восстанавливать из бэкапа сам GitLab, прежде чем команда разработки смогла полноценно включиться в работу по развертыванию сервиса на новой площадке. Почему мы так подробно описываем эти технические моменты? Скрыть эти факты и свалить всю вину на провайдера было бы проще, но это было бы неправдой. Доверие, которое вы нам оказали, обязывает нас быть честными до конца и даёт вам право на правду, какой бы неудобно для нас она ни была.

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

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

Восстановление и тактические победы

Время шло. На «третьем фронте» кипела работа. Огромная база данных медленно восстанавливалась из резервной копии на мощностях нового партнера. Этот процесс, для тех, кто не знаком с техническими деталями, невероятно сложен и долог — он включает в себя не только копирование гигабайт данных, но и перестроение индексов и проверку целостности. Одновременно восстановленный GitLab позволил нашей команде начать разворачивать остальные компоненты инфраструктуры. И тут со «второго фронта» стали поступать обнадеживающие новости! Команда основного провайдера, наконец, добилась прогресса, и появилась надежда на скорое восстановление доступа к нашей основной инфраструктуре.

Перед нами встал стратегический, принципиальный выбор: остановить тяжелый и дорогостоящий процесс восстановления на резервной площадке и ждать «официального» решения или продолжать? Мы приняли решение не прекращать работы по развертыванию «ковчега», лишь незначительно снизив их приоритет. Мы не могли позволить себе отказаться от спасательной шлюпки, пока не убедимся на 100%, что основной корабль не просто на плаву, а готов к плаванию. Именно в этой напряженной гонке со временем нам удалось проявить нужную изобретательность, одержав несколько ключевых тактических побед, которые значительно смягчили последствия сбоя. Во-первых, благодаря личным контактам мы смогли связаться с основной командой ВКонтакте. Мы уведомили их о масштабном сбое, что позволило предотвратить автоматическое отключение наших callback-серверов со стороны ВК. У них есть правило: если получатель уведомлений долго недоступен, его настройки могут быть удалены. Наше общение с командой ВКонтакте спасло настройки в тысячах ваших сообществ.

Во-вторых, наша команда смогла оперативно восстановить один из самых критичных компонентов — систему приема входящих запросов от ВКонтакте и Telegram. Для ее работы не требуется доступ к основной базе данных. Это был отличный ход, который позволил нам начать «собирать» все входящие сообщения в очередь, пока основной сервис был недоступен. Именно благодаря этому мы смогли сократить реальную потерю данных с почти 30 часов простоя до всего нескольких часов.
В конце концов, в 15:40 в пятницу, доступ к основной инфраструктуре был полностью восстановлен. Мы получили подтверждение, что все данные и конфигурации в целости и сохранности — сбой затронул исключительно сетевой сегмент. Кризис миновал.

Уроки: строим более устойчивое будущее

Каждый кризис — это дорогой, но бесценный урок. Мы вышли из него не только с восстановленным сервисом, но и с фундаментально новым пониманием того, что такое надежность. Мы всегда понимали, что построение системы с надежностью в «девять девяток после запятой» (99.9999999%) — это в большинстве случаев экономический популизм. Каждая дополнительная девятка экспоненциально увеличивает сложность и стоимость, что может сделать сервис нерентабельным.

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

Урок 1: От поставщиков к партнерам. Самый главный вывод не технический, а организационный. Мы пересматриваем наши отношения с поставщиками.

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

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

Урок 3: От резервных копий к реальным планам. Этот кризис показал: мало иметь резервные копии, важно иметь отработанный и предсказуемый план их развертывания. Мы переходим от простого обладания «спасательным жилетом» к регулярным учениям по его использованию. Процессы аварийного восстановления будут формализованы, задокументированы и, что самое главное, будут регулярно тестироваться.

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

Что в итоге

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

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

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

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

Причины «сбоя системы»

что происходит
Спасибо, что вы с нами.

Впереди много работы, и мы уверены, что вместе мы станем только лучше!
Следите за нашими новостями:
Команда
Senler.ru