Привет.
Любой бизнес учится на собственных ошибках, во всяком случае, так поступают те, кто пытается выстроить работающий бизнес. В мире существуют мириады угроз, от сбоев и ошибок не застрахован никто, вопрос только в том, какие выводы бизнес из них делает, как адаптируется к новым условиям.
Многим кажется, что история масштабного сбоя службы доставки CDEK началась 25 мая 2024 года, когда перестали работать сайт и приложение, а все отправления де-факто потерялись на какое-то время. К сожалению, это не первый масштабный сбой, в октябре 2018 года компания не работала три недели. Причина в сбое компьютерных систем, переходе на новую платформу. В 2019 году в CDEK активно нанимали сотрудников в IT-департамент, казалось, что компания сделала выводы из произошедшего.

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

27 мая. В компании признают очевидное — не работают сайт и приложение.

28 мая. В CDEK переходят на ритм в два сообщения, обещают восстановить сервис к 29 мая.


29 мая. Работа CDEK не восстановлена, компания сообщает, что работает над исправлением ситуации.

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

Параллельно хакерская группа Head Mare берет на себя ответственность за взлом CDEK, но компания никак этого не комментирует. Равно и не обращается в РКН с сообщением о том, что к персональным данным клиентов кто-то получил доступ, по закону компания обязана сообщать об утечках.
Начиная с 26 мая на рынке активно обсуждается, что хакеры взломали всю систему CDEK, использовали вирус-шифровальщик. Фактически под нож ушла вся система компании, что привело к таким результатам, она до сих пор не восстановлена.
И вот тут начинается самое интересное, ведь компания не сообщает никаких подробностей об инциденте, старается ничего про него не говорить. Обсуждая сбой компьютерной системы, в CDEK молчат о его причинах. И такое молчание легко объяснимо — слишком детские ошибки в защите собственной системы, слишком дырявой она оказалась для атакующих.

В аккаунте соцсети Х хакеры Head Mare выложили целый ряд скриншотов, которые они приписывают внутренним системами CDEK. Все вместе выглядит как не слишком добротно сделанный фейк, представить, что компания с такими оборотами не использует проверенные IT-решения, делает бэкапы раз в полгода, невозможно. В этой истории каждая сторона преследует свои цели, так что доверять чьим-то словам я бы точно не стал.
Почему я уверен, что CDEK все эти годы жестко экономил на IT-инфраструктуре, повышал свою прибыль в ущерб безопасности? Ответ очевиден, мы видим то количество сбоев и утечек информации, что происходит в CDEK, но не находит исправления в последующем. В 2022 году компания допустила утечку информации о своих клиентах, их заказах. Утечка была масштабной. Странным образом по ее итогам в социальных сетях появился нарратив: данные утекают у всех, CDEK — просто одна из компаний. Думаю, что это был своего рода антикризис, представить, что какие-то люди вдруг изъявили желание поговорить об этом, сложно.
При наличии сохраненных бэкапов восстановить работоспособность любого сервиса — дело десятков минут, в худших ситуациях — часов. Но никак не дней. И если происходит так, что нужно восстанавливать свою систему целыми днями, то у вас просто нет IT-направления или оно слишком слабое. На сотрудниках из IT в CDEK, видимо, экономили, никак иначе объяснить происходящее нельзя. Та же «Почта России» не может похвастаться аналогичными сбоями в последние годы, уровень защиты данных в этой госкорпорации значительно выше. И можно даже не понимать, как все устроено, а судить по фактам, по тому, что происходит и что утекает вовне.
Сколько будет длиться сбой CDEK? Вопрос остается открытым, компания на него никак не отвечает. Ежедневные обещания не воплощаются в жизнь, раздражение клиентов нарастает, так как у многих в доставке важные вещи — лекарства для животных, растения и так далее. В 2023 году ежедневный оборот CDEK составлял до 191.8 млн рублей. Можете смело считать, сколько компания потеряла на простое, но также приплюсуйте сюда необходимость привлечения IT-специалистов, построения новой системы и так далее. Все вместе обойдется CDEK в пару-тройку миллиардов рублей. Чем дольше сбой, тем выше убытки.
Партнеры CDEK, которые использовали службу доставки, также терпят убытки, их товары зависли. Как результат, клиенты могут отменять доставку, что ведет к прямым убыткам. Как минимум несколько партнеров компании планируют добиваться компенсаций в судебном порядке. И это также ляжет на CDEK дополнительным бременем.

С точки зрения бизнеса у CDEK все более-менее хорошо, за исключением того, что компания полагается на заемные средства и может просто не выдержать большого числа судов, если сбой продлится долго и принесет дополнительные убытки. Уже на данный момент размер сбоя таков, что для CDEK он скажется на всех показателях 2024 года. Причина же происходящего в одном — компания не защищала свои данные и свою инфраструктуру на достаточном уровне, экономила на этом. И это происходит не впервые, отсюда вывод — что-то поправят, сервис как-то заработает, а потом снова произойдет «сбой». Причина не в угрозах извне, а в недостаточном финансировании защиты данных. Увы, это системная проблема.
Тем, у кого зависли посылки, сочувствую, но тут нужно ждать, пока компания оживет и начнет их выдавать. Хочется верить, что это случится со дня на день, так как пора уже работать в ручном режиме, проблема слишком затянулась.
> представить, что компания с такими оборотами не использует проверенные IT-решения, делает бэкапы раз в полгода, невозможно.
Очень даже возможно. Это только на конференциях вам рассказывают как космические корабли бороздят просторы серверных…
А на деле убитое железо, персонал низкооплачеваемые бомжефрики, которые увольняясь уносят свое знание что как работает с собой, и костыль на костыле, которые оные мастера и городят…
>CDEK все эти годы жестко экономил на IT-инфраструктуре,
Скорее всего акционер деньги выделял. Просто их рассовывали по карманам эффективные менеджеры от it.
Владимир Репин, Вот меня удивляют люди, живущие в мире розовых пони, где никто не имеет право на ошибку. При этом к себе, почему то, такие критерии не выставляют — "меня то за что".
А в данном случае это не ошибка, а намеренная экономия на ИТ со стороны руководства компании. Ибо сделать просто функционирующую систему и сделать такую же систему, но защищённую от взлома — стоит разных данег, хорошо если просто в разы, а не на порядки.
Если попробовать перейти в зыбкий мир аналогий, то это пример может быть примерно таким: есть "простое" колесо для автомобиля, которое можно проколоть при наезде на гвоздь или камень. И такое колесо стоит х-денег, но его периодически, с разной вероятностью, придётся чинить/менять. А может и не придётся. А есть колесо, которое ДОЛЖНО выдерживать наезд на любое (почти) препятствие, и оставаться после этого работоспособным. И внезапно окажется, что разработка такого колёса стоит в 3 раза дороже, итоговое производство — в 5, весить оно будет в 3 раза больше, потребует специальных колёсных дисков, тормозов и спец. оборудование для монтажа. И 99,999% пользователей такое колесо не нужно.
+- так же и в ИТ. Руководство заплатило за функциональный продукт. За безопасность не платило, т.к. это будет стоить кратно дороже: и специалисты нужны другого уровня с другими з/п, и сам процесс разработки такого ПО сильно отличается.
Наказать "кого попало" всегда можно. Но если вы платили за одно, а наказываете за другое — то дурак таки заказчик, а не исполнитель.
ReadN, И в момент подключения диска, на него радостно набрасывается шифровальщик. Защитить от такого могут сетевые коммуникации.
Но шифровальщик может сидеть как раз не на резервируемом ПК, а на бекап-сервере. Вероятность этого растет, если этот сервер исполняет и другие роли. Вот сидел он, сидел, целый год сидел, а потом к нему обратились "Дай резервную копию!", в ответ…
Ssn, Правильно делать бекапы (и потом проверять :), не бог весть какая квалификация.
Предположу, что шифровальщик проник на бекап-сервер. Тут, действительно, нужна высочайшая квалификация безопасников, что бы такой факт вовремя определить.
мимoпроходил, На конференциях обычно выступают представители ИТ-компаний или тесно завязанных на ИТ. Там всё в порядке. А СДЕК — обычный завод, пусть и распределенный. Где ИТ выполняет вторичные функции. Тут да, см. перечисленное вами и даже хуже.
Играют в молчанку потому как их IT безопасность обеспечивала дочка Сбера. У этого сберовского ООО заказов только от Мнцифры на ярд, от Сбера на сотни миллионов, от МВД итд итп. Поэтому такая тишина.
Lecron, Правильно иметь отдел по безопасности, и слушать их когда они говорят что нужно делать.
ReadN, Научись так же и ломай что пожелаешь
JUST4, Зачем вообще что-то ломать
Владимир Репин, А что на производствах творится — лучше не говорить! Даже президент неоднократно говорил, что кадровый кризис в стране не на один год. Деньгами тут ситуацию кардинально не исправишь. Нужен комплексный подход к подготовке и отбору кадров. Не дело, когда не могут найти нужного специалиста, занижают требования к нему, зарплату при этом делая выше рыночной, чтобы не переманили. Это иррациональный подход, который только усугубит кризис кадров.
Sedze-007, На фельетон тянет!
Владимир Репин, Точно а еще бы круто, чтоб как в 90-е — прокинуть весь отдел на бабки на пару месяцев, купить беху да давить пешеходов, ты ж откупишься, а в случае ЧП свалить все на сторожа/охранника/рабочего как с теме же стройками было и потом удивляться почему такой отток мозгов)
Ssn, Классика. Аудит проекта у безопасников, особенно если это внешняя контора — это долго и дорого, bugbounty — тоже дорого и страшно, свой отдел долго, дорого и вообще за что им платить. В итоге очередной менеджер предлагает, что лучше давайте наберем еще фич, чтобы графики по привлечению были красивые. В итоге если ему даже говорят что не закрытая ручка торчит, с которой можно вычитать базу, бывает отмахиваются. Это все помноженное на то что при собеседованиях до сих пор не умеют толком менеджеров оценивать и текучки на проектах и приводит к интересным результатам.
Владимир Репин, Дак не платите, это точно никак не связано с тем что часть их вместе с СВО стала недоступна для найма в России.
ReadN, НУ зачем учится на врача? Есть более простые и выгодные профессии. Из этого разряда вопрос. Ломают потому что могут. Как в песне — не умеешь строить мосты, умей их жечь.
chaotism, Вам 12 лет? А нет. Посмотрел профиль. Регистрация 30 мая. Бот или провокатор.
Владимир Репин, Тут не право на ошибку, а в системности.
Нельзя в принципе создать отказоустойчивую систему, если в ТЗ прописан только прикладной функционал.
Т.к. по трудозатратам это сравнимо, а если оплачивать и проверять никто не будет — то и делать некогда, и без проверки оно бессмысленно.
Вот тупо, даже без учёта трудоёмкости разработки, аппаратные средства для бэкапов + последующих ресторов — это +- такое же железо, как для production: чтобы прод бэкапился за разумное время и было куда восстанавливать, чтобы проверить, что восстановилось правильно.
Это уже не говоря о том, что для более-менее сложной распределённой системы, бэкап — это не просто строчка "BACKUP DATABASE prod", а целая система, которая должна делать согласованный снепшот за разумное время, и потом так же согласованно его восстанавливать, что может сильно повлиять на архитектуру всей системы (и явно не в лучшую сторону с точки зрения скорости работы и скорости разработки новых фич).
И если руководство на это не выделяет бюджет — то даже грамотные бэкапы сделать не получится. Не говоря уже о компетенции специалистов, которые это смогут грамотно сделать, и явно не за 2 копейка (+ ночные бдения за x2 оплату).
Владимир Репин, Достаточно одного засланного козачка (или топ-менеджера, который плевать хотел на все эти ограничения IT и флешку пихает куда попало, выбив себе такие права), чтобы обойти все политики безопасности. "Сто раз твердили миру": главная дыра в безопасности — это люди.
А грамотный бэкап — это большие деньги, отдельные от разработки, и в первую очередь — на железо, а не только на "тунеядцев".
И пока бизнес не получит убытки от взлома большие, чем за безопасность/отказоустойчивость — бизнес эти деньги тратить не будет.
Lecron, Угу, только для этого надо:
1. Куда делать бэкапы. Если хоть немного подумать, то неожиданно окажется, что бэкап-сервер будет стоить примерно столько же, сколько основной prod, ибо бэкапы нужно делать быстро и хранить много и долго (минимум 6 ежедневных + 3 еженедельных + 5-12 ежемесячных)
2. Как проверять бэкапы. Назад на прод зали… тьфу, ерунду спорол. Ещё сервер(а) нужны, сравнимые по мощи (и цене) с продом.
3. Кто будет делать бэкапы. Кто-нить из команды разработчиков, в "свободное от работы" время? Или таки отдельные люди, с конкретными обязанностями и с которых потом спросить можно за их невыполнение? И работать им, помимо прочего, придётся иногда, но вполне регулярно, по ночам за 2 ставки, ибо временное окно "спокойного ночного времени" при наличии офисов от Калининграда до Чукотки, внезапно, часа 2-3 всего.
И за чей счёт банкет?
Или по прежнему "тунеядцы" во всём виноваты, а руководство уже за всё заплатило, когда тз написало?