Архитектурные катастрофы — часть 5: как Cloudflare упал из-за кривого SQL-запроса

18 ноября 2025 года Cloudflare пережил, возможно, свой худший сбой с 2019 года. Глобальный прокси, защищающий и ускоряющий значительную часть интернета, начал отдавать 5xx ошибки, утянув за собой тысячи клиентов.

🔥 Что произошло?

В 11:20 UTC мониторинг зафиксировал резкий скачок 5xx ошибок на уровне Core Network. Трафик перестал маршрутизироваться корректно.

Симптомы напоминали классическую мощную DDoS-атаку: система то падала, то восстанавливалась (флуктуировала). Это сбило команду с толку — инженеры начали искать внешнего врага.

Однако реальность оказалась прозаичнее: система убила сама себя изнутри. Проблема затронула не только клиентский трафик, но и внутренние сервисы: Turnstile, Workers KV и Dashboard.

🧠 В чем причина?

Корень зла крылся в изменении прав доступа в кластере ClickHouse, который генерирует конфигурационные файлы для системы Bot Management.

🔹 Триггер: Инженеры выкатывали улучшение безопасности, делая доступ к таблицам явным. В 11:05 был применен патч, который позволил запросам видеть метаданные не только виртуальной базы default, но и физической базы r0 (шарды).

🔹 Логическая ошибка: SQL-запрос, собирающий "фичи" для ML-модели, выглядел так:

SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;

Он не фильтровал по имени базы данных. Раньше это работало, потому что видна была только одна база. После апдейта прав запрос вернул дубликаты столбцов (от default и от r0).

🔹 Эффект снежного кома:

1. Файл конфигурации ("feature file") удвоился в размере из-за дубликатов.

2. Этот файл улетел на все прокси-серверы сети (FL — Frontline).

3. Код на Rust, читающий этот файл, имел hard limit на количество фичей (около 200) для преаллокации памяти. Реальное использование было ~60, но дубликаты пробили лимит.

4. Результат — паника в Rust:

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value.

Да, глобальная сеть упала из-за unwrap() на ошибке валидации размера конфига.

📉 Последствия и ущерб

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

Последствия от падения сервисов:

🔸 Core CDN & Security: 5xx ошибки для конечных пользователей.
🔸 Turnstile: Капча перестала грузиться, заблокировав входы на тысячи сайтов.
🔸 Workers KV: Отказ шлюза из-за падения прокси.
🔸 Dashboard: Клиенты Cloudflare не могли залогиниться, чтобы понять, что происходит (потому что логин защищен упавшим Turnstile).

🙉 Ирония дня: Status Page (хостится отдельно) тоже упал, но по совпадению, что окончательно убедило инженеров в версии "нас атакуют по всем фронтам".

Из-за этого сбоя были недоступны X (который Twitter), ChatGPT, сервисы Anthropic и другие.

🛠 Как инженеры Cloudflare исправили ситуацию?

Первые полтора часа ушли на ложный след (DDoS) и попытки изолировать проблему трафиком.

🔹 Диагностика: Когда стало понятно, что атаки нет, инженеры коррелировали сбой с генерацией конфигурации Bot Management. Флуктуации объяснялись тем, что ClickHouse кластер обновлялся постепенно: "старые" ноды генерировали хороший конфиг, "новые" — плохой.

🔹Локализация: В 14:24 была полностью остановлена автоматическая пропагация новых конфигурационных файлов.

🔹Rollback: Инженеры вручную залили "известно хорошую" (last known good) версию файла в очередь дистрибуции.

🔹Перезагрузка: Пришлось форсированно перезагружать Core Proxy, чтобы сервисы вышли из состояния паники. Основной трафик восстановился к 14:30.

Полное восстановление заняло почти 6 часов (с 11:20 до 17:06 UTC).

🔍 Что можно было сделать, чтобы не допустить такое происшествие?

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

🔐 Security Risk Management | 2 декабря в 20.00 (GMT+3)

Как построить работающую систему управления рисками безопасности - от первых тревожных сигналов до конкретных действий?

Что обсудим:
1️⃣ Как выявлять угрозы на уровне архитектуры: threat modeling, типовые атаки, связь решений и рисков
2️⃣ Inherent vs Residual Risk — что это и почему важно различать
3️⃣ Как собрать рабочую risk-model: фреймворки, матрицы, приоритизация
4️⃣ Как архитектура напрямую влияет на безопасность продукта
5️⃣ Как переходить от анализа к действию: mitigation, response, чек-листы, кейсы

🎙 Спикер: Андрей Якушин, Solution Architect и Engineering Manager с 18+ годами опыта в IT.

Регистрация

Какие навыки развивать сеньору, чтобы не отставать от рынка и расти по карьере?

📺 Приглашаем на открытый митап [Технический Лидер] с Павлом Вейником.

Павел — ex-Architect Miro и EPAM, CTO стартапов и основатель Hard&Soft Skills. За его плечами 20+ лет в разработке и более 1000 обученных инженеров, из которых 450+ — техлиды, архитекторы и CTO. Он точно знает, как устроен переход на следующий грейд.

🗣 Что будем обсуждать

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

🔹 Влияние AI: реальная ситуация на рынке труда и стоит ли разработчикам и архитекторам опасаться “тумана AI”.

🔹 Рынок и деньги: обзор зарплат и спроса на техлидов и архитекторов в СНГ и Европе.

🔹 Битва ролей: четко разграничим зоны ответственности Tech Lead, Team Lead и Architect.

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

👋 Кому будет полезно

Ждем backend-разработчиков уровня Senior, действующих техлидов и solution-архитекторов, которые хотят развиваться и ищут новые вызовы.

🗓 Дата и время: 16 декабря в 19:00 (GMT+3)

🔗 Регистрируйтесь по ссылке и задавайте свои вопросы!

Внутрянка Enterprise-разработки: как выживают большие банки между SAFe, безопасниками и техдолгом — выводы Архитектурного трёпа #130

🏢 Структура Enterprise: Трайбы, Арты и выбор методологии

Когда IT-департамент разрастается до 600+ человек (плюс вендоры), плоская структура умирает. Иерархия выстраивается от Трайбов (по линиям бизнеса) к IT-стримам, которые делятся на Арты (отвечают за системы или их части), и только в конце цепочки стоят конкретные команды

Выбор между Scrum и Kanban здесь — это не вопрос вкуса, а вопрос функции

Продуктовые команды, сфокусированные на изменениях (Change) и новых фичах, живут по Scrum

Команды, работающие с операционкой, поддержкой и стабильным потоком задач (Run), выбирают Kanban

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

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

🔄 Жизненный цикл бизнес-потребности и планирование

Чтобы бизнес-идея дошла до продакшена, процесс выстроен через жесткие фильтры и этапы согласования:

🔸 Ролевая трансформация: Потребность формулируют бизнес-технологи, а IT-технологи (аналог системных аналитиков) превращают их в BPMN-схемы для архитекторов

🔸 Дорогое планирование: Раз в квартал вся разработка останавливается на три дня, чтобы команды синхронизировались и проставили зависимости друг на друга

🔸 Проектная надстройка: Для сложных внедрений, затрагивающих множество систем, вводится слой проектного управления, где PM управляет ресурсами сразу нескольких команд, иногда конфликтуя с их текущими планами

Бизнес всегда формулирует потребности больше, чем может сделать IT. Что успели — выполнили, что не успели — переприоритизируйте и повышайте важность

📉 Священные 20% на Технический долг

В зрелом Enterprise борьба с энтропией заложена в процесс. Неважно, горит ли план у бизнеса — 20% емкости команды железно резервируется под техдолг

Приоритизацией этого долга занимаются IT-лидеры (техлиды направлений) и архитекторы

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

Как бы бизнес ни хотел присунуть еще какую-нибудь потребность, команды четко считают, чтобы 20% осталось на технический долг

⏱️ Оценка сроков и войны с Project Manager'ами

Разработчики склонны мыслить "идеальным" временем кодинга, забывая про реальность

Чтобы не срывать сроки, опытным путем вывели формулу трех времен:

🔹 Чистое время — сколько часов нужно, чтобы просто написать код

🔹 Грязное время — код плюс кофе, митинги и контекстные переключения

🔹 Календарное время — грязное время плюс выходные, праздники и код-фризы

PM часто пытаются продавить команду на сделать побыстрее/подешевле. Защита строится на метриках (velocity/capacity) и эскалации рисков

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

Программист поставил 8 часов. Но грязного времени это будет 12-16, а календарное еще и с выходными. Заказчику надо календарное время показывать, иначе вы все время будете срывать срок

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

Инфраструктура банка и организационные изменения накладывают свои ограничения на скорость и удобство работы:

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

🔸 Тренд на ITSM: Архитекторы, DevOps и QA выводятся из команд в отдельные сервисы и заказываются по запросу, как услуги

🔸 Риск потери контекста: Главная проблема модели — приходящему "как сервис" специалисту нужно слишком много времени на погружение в незнакомую систему

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

Кэширование и консистентность: практические компромиссы

➡️ От бизнес-метрики к SLA на свежесть

Первый вопрос при проектировании кэша — сколько денег мы потеряем, если пользователь увидит данные 5-секундной давности?

Формализация требований начинается с определения окна неконсистентности

Для ленты новостей eventual consistency с лагом в минуту приемлем. Для баланса кошелька или статуса заказа нужен read-your-writes

Если мы не можем обеспечить строгую консистентность в распределенном кэше (из-за асинхронной репликации или сетевых задержек), честнее ходить в мастер БД

Фиксируйте SLA на свежесть (Freshness SLA):

🔹 Strong: 0ms лаг (обычно отсутствие кэша или синхронная инвалидация с блокировками)
🔹 Bounded Staleness: Данные могут отставать на X секунд или N версий
🔹 Monotonic Read: Пользователь не должен видеть новую версию, а потом старую из другой реплики

🏗 Паттерны под профиль нагрузки

Выбор стратегии зависит от соотношения Read/Write и стоимости прогрева. Redis Cache-Aside — дефолт, но он плох при холодном старте и сложных агрегатах

🔸 Read-Through / Write-Through: кэш становится основным интерфейсом доступа. Упрощает код приложения, но жестко связывает схему кэша с хранилищем. Идеально для простых key-value моделей

🔸 Write-Behind (Write-Back): Асинхронная запись в БД. Снижает latency записи и сглаживает пики (batching), но создает риск потери данных при падении узла кэша. Оправдано для счетчиков (лайки, просмотры), где потеря пары инкрементов не критична

🔸 Near-Cache (L1/L2): Локальный in-memory кэш в ноде сервиса + удаленный Redis. Дает микросекундный доступ, но порождает проблему когерентности локальных кэшей. Требует Pub/Sub канала для инвалидации (Redis Pub/Sub, Kafka), иначе разные инстансы сервиса будут отдавать разные данные

⚡️ Гонки, инвалидация и thundering herd

Самая большая боль — конкурентный доступ. Простой SET поверх старого значения ведет к lost updates, а инвалидация без стратегии — к thundering herd (лавине запросов в БД при протухании горячего ключа)

Чтобы избежать "дырок" и гонок:

🔹 Версионирование (Logical Clock/ETag): Храните в кэше версию объекта. При записи проверяйте, что версия в базе выше версии в кэше (CAS-операции). Если нет — инвалидируем, а не перезаписываем

🔹 Probabilistic Early Expiration: Чтобы избежать одновременного похода сотен потоков в БД при истечении TTL, начинайте пересчитывать значение до реального протухания с вероятностью, растущей по мере приближения дедлайна (алгоритм X-Fetch)

🔹 Two-phase Invalidation: Вместо обновления данных в кэше — удаляйте их. Паттерн «обновил базу — удалил из кэша» безопаснее, чем «обновил базу — записал в кэш», так как второй вариант уязвим к гонкам перезаписи

🔗 Границы транзакций и источник истины

В распределенных системах кэш часто становится частью Read-модели (CQRS). Здесь возникает дилемма: Dual Writes. Если приложение пишет и в БД, и в кэш/индекс, рано или поздно один из вызовов упадет, и вы получите рассинхрон

Решение — Transactional Outbox или CDC (Change Data Capture)

Приложение пишет только в БД (Source of Truth). Коннектор читает WAL-лог базы и отправляет события изменений в шину, откуда консьюмеры обновляют/инвалидируют кэш

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

🔍 Проверка в проде: hit ratio врет

Высокий Hit Ratio (99%) может скрывать тот факт, что вы отдаете безнадежно устаревшие данные. Метрики успеха кэширования — это не только попадания, но и Staleness Metric

Как проверять корректность:

🔸 Shadow Traffic / Dual Reads: На 1% запросов читайте и из кэша, и из БД. Сравнивайте хеши ответов. Логируйте расхождения как инциденты

🔸 Chaos Engineering: Искусственно замедляйте ответы БД или рвите соединение с Redis. Проверяйте, не происходит ли каскадный отказ (fallover), когда вся нагрузка перетекает на "холодную" базу

🔸 Canary Caching: Выкатывайте новую стратегию инвалидации сначала на один шард или группу ключей, отслеживая аномалии в бизнес-метриках (например, резкий скачок отмен заказов может говорить о показе неактуальных остатков)

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

Испорченный телефон

В найме у каждого свои интересы и картина реальности:

➖Менеджер хочет закрыть вакансию и обеспечить delivery
➖Рекрутер – дать как можно больше кандидатов на выбор
➖Технический интервьюер проверяет скилы (а иногда и выпендривается)
➖Команда хочет, чтобы их не отвлекали

Каждая роль размывает реальные требования к кандидату (потому что не понимает их) и добавляет лишние (зато понятные). В итоге вакансия превращается в поиск единорога.

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

AI, автоматизация – гонка пушки и брони

Автоматические платформы рекрутеров сверяют ключевые слова вакансии и резюме. Остаются те, кому повезло смэтчиться по 10 разным терминам из существующих 500.

А на стороне кандидатов – резюме из ChatGPT и авто-отклики.

Результат? Сотни нерелевантных откликов, и работодатели, которые не могут найти сотрудников. И с обеих сторон мешающая автоматика.

Система настроена отбрасывать неподходящих, а не искать подходящих.

А на интервью на джунские и мидловые позиции появляется еще и страх "Они сидят с ChatGPT!"

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

Компании проверяют не то

Спрашивают: "Знаешь ли ты, как работает такой-то метод такого-то фреймворка?"

Вместо этого надо проверять:

➖Как человек учится и как быстро вникает в новую область
➖Какие темы его реально зажигают
➖Как он работает с незнанием: игнорирует или системно закрывает пробелы

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

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

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

Или в инженере, который не умеет учиться. Но сколько таких инженеров среди общей массы?

Лучшие кандидаты всегда не попадают в требования. Зато у них есть мотивация, способность учиться и реальный интерес. На этом строится сотрудничество: кандидат растет, менеджер получает сотрудника, который делает delivery. Win-win для всех.

Проблема роли рекрутера

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

Радикальный, но честный взгляд: рекрутер в инженерном найме – это швейцар у двери.

Максимум, что он реально может и должен делать:

➖Проверить базу: стаж, локацию, вилку, рабочий статус
➖Аккуратно донести до кандидата контекст и ожидания
➖Не искажать картину мира своими интерпретациями

Все остальное – задача менеджера и техлида.

Когда рекрутер проверяет "химию с командой" – это бред. Они не в состоянии это сделать. Это вредит компании, команде и кандидату.

Рекрутер накладывает ошибочные представления о команде на ошибочные представления о кандидате. В результате он оценивает одну свою проекцию с помощью другой (проекция здесь – термин из психологии).

Идеальный сценарий найма

➖Не сотни резюме, а 10–15 адекватных откликов
➖2–3 кандидата в шорт-листе
➖Один оффер
➖Неделя продуманного онбординга, после которой видно, как человек работает, чему научился и как взаимодействует с командой

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

📢 Уже сегодня OWASP Top-10 2025: новые угрозы, новые приоритеты
🗓 11 декабря в 20.00 GMT+3

OWASP выкатили обновление своего легендарного Top-10 - списка самых критичных уязвимостей в веб-приложениях.

Если коротко: что такое OWASP?
Это международное сообщество, которое формирует лучшие практики по безопасности приложений. Их Top-10 - главный ориентир для инженеров, тимлидов и архитекторов по тому, на что реально стоит обращать внимание в защите продукта.

В докладе разберём:
• что нового появится в OWASP 2025 и почему;
• чем версия 2025 отличается от 2021;
• куда сместились реальные угрозы;
• как изменения повлияют на архитектуру, код и процессы безопасности.

Спикер: Андрей Якушин, Solution Architect и Engineering Manager с 18+ годами опыта в IT.

👉 Регистрация
👋 До вечера!

Анти‑паттерны CI/CD: скорость без хаоса

Скрытые архитектурные узкие места, которые превращают доставку кода в bottleneck и убивают стабильность релизов

🏗 Pipeline as Monolith: Единая точка отказа

Мы привыкли декомпозировать монолитные приложения, но часто оставляем монолитным сам процесс доставки

В такой схеме пайплайн – это огромный файл yaml или Jenkins, где сервисы, тесты, линтинг и деплой жестко сцеплены в единый артефакт

Это создает неоправданно большой blast radius: изменение конфигурации для одного микросервиса может сломать сборку для десяти других

Время выполнения растет нелинейно, а CI превращается в бутылочное горлышко, где команды стоят в очереди на мердж

Решение – Pipeline as Product

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

Критически важно обеспечить возможность локального тестирования шагов пайплайна и внедрить CI-sandbox для обкатки изменений в логике доставки

🕸 Игнорирование тестов как долговая яма

Самый коварный вид техдолга в CI – это тесты в статусе quarantined или skipped без жестких обязательств по их починке

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

Тест-карантин имеет смысл только при жестком администрировании:

🔹 Strict SLA: Тест не может находиться в карантине дольше 24-48 часов

🔹 Mandatory Root-Cause: Каждое попадание в карантин должно сопровождаться анализом: это проблема инфраструктуры, гонка данных или логическая ошибка?

🔹 Ownership: У каждого теста должен быть owner. Автоматизированные реплики окружения для воспроизведения падения должны создаваться по кнопке

🚦 Параллелизация без наблюдаемости

В погоне за скоростью мы агрессивно распараллеливаем джобы. Но без трассировки и квот это приводит к nondeterministic failures

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

Для управляемой скорости необходимы:

🔸 Distributed Tracing в CI: Внедрение correlation IDs для шагов сборки, чтобы видеть, на каком этапе происходит просадка

🔸 Resource Quotas & Limits: Жесткое ограничение ресурсов на контейнер сборки

🔸 Deterministic Ordering: Для критически важных шагов порядок должен быть гарантирован

🎭 Иллюзия паритета окружений

«У нас всё в Docker, значит везде одинаково» – опасное заблуждение

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

В итоге инциденты при масштабировании случаются именно там, где «всё работало в CI»

Чтобы минимизировать разрыв между стейджем и продом:

🔸 Infra-tests в CI: Тестируйте не только код, но и инфраструктуру

🔸 Feature Flags: Отвяжите релиз фичи от деплоя кода, используя progressive delivery

🔸 Contract Testing: Используйте Pact или аналоги для проверки контрактов между сервисами

🔸 Immutable Infrastructure: Любое изменение конфигурации сервера – это пересоздание инстанса

📦 Мутабельные артефакты и неявные зависимости

Деплой по тегу latest или пересборка бинарников специально для продакшена – грубейшее нарушение принципа воспроизводимости

Если вы пересобираете артефакт для следующего окружения, вы деплоите не то, что протестировали

Гарантия целостности поставки строится на жестких принципах:

🔹 Content-addressable IDs: Идентификация артефактов только по их хешу (SHA), а не по семантическим версиям

🔹 Binary Provenance: Подпись артефактов (например, через Sigstore) на этапе сборки. CD-система должна проверять подпись перед деплоем (Policy Gates)

🔹 Vendor Dependencies: Использование lockfiles и локальное кеширование (или вендоринг) всех внешних зависимостей

Куда расти, когда ты уже senior, но карьера стоит на месте? Уже сегодня вечером узнаете на митапе [Технический Лидер]!

🔍 О чем пойдет речь

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

В программе встречи:

🔸 Ловушка Сеньора: Почему углубление в код и новые технологии больше не гарантируют рост дохода и что нужно качать на самом деле.

🔸 Туман войны: Как AI, массовые увольнения и экономия бюджетов влияют на требования к инженерам и как оставаться востребованным в этом хаосе.

🔸 Разбор ролей: Четко разграничим понятия Тимлид, Техлид и Архитектор — кто за что отвечает и почему в разных компаниях это разные люди.

🔸 Навыки Senior+: System Design, Distributed Systems и понимание бизнеса — как эти скиллы конвертируются в офферы.

🚀 Почему это важно

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

🎤 Ведущий

Павел Вейник — ex-Architect Miro и EPAM, CTO стартапов и основатель Hard&Soft Skills. За его плечами 20+ лет в разработке и более 1000 обученных инженеров. Он точно знает, как устроен переход на следующий грейд.

📆 Когда: сегодня в 19:00 (GMT+3)

🔗 Регистрация по ссылке

Как выживать инженерам в мире юристов, регуляторов и безумных требований — выводы Архитектурного трёпа #131

⚖️ Битва за архитектуру: диалог с юристами

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

🔸 Широкая трактовка: Юристы пытаются прикрыть компанию от любых рисков, что часто ломает или усложняет архитектуру приложения

🔸 Непонимание ответственности: Разработчикам стоит всегда уточнять: “Какая ответственность за нарушение?”. Часто выясняется, что это лишь предупреждение или нулевой штраф, что позволяет бизнесу принять риск и не переделывать систему

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

🔒 Безопасность vs Удобство: закрытые контуры и PCI DSS

Регуляторные стандарты и паранойя безопасности создают реальные барьеры для инженерии:

🔹 Влияние PCI DSS: Эти требования — не просто формальность; они могут заставить переписать структуру приложения так, что она будет сильно отличаться от изначально спроектированной

🔹 Боль закрытых контуров: Полная изоляция (без доступа к интернету и ChatGPT) мешает работе настолько, что становится причиной увольнения лидов

🔹 Проблема тестовых данных: Чтобы не держать на стейдже реальные email/телефоны, приходится писать коленочные скрипты, которые по ночам обезличивают продовые дампы.

Если вы хотите использовать GPT, то вы переключаетесь, что-то там гуглите, переключаетесь, VPN обратно включаете... чувак там просто уже вешался и не мог нормально работать

🛠 Технические костыли и смерть фичей

Иногда регуляция заставляет строить монстров или вовсе убивает продукт:

🔸 Фильтр для экономии: Госсервис биометрии берет плату за каждый запрос. Решение — поставить перед ним свой "безлимитный" движок, который мучает юзера до получения идеального кадра, и только потом отправляет запрос в платную систему

🔸 Юридический блок: Бывают кейсы, когда фичу реализуют в авральном режиме, но юристы клиентов запрещают её покупать

🔸 Внезапная смерть стартапа: Провайдер счетов может разорвать контракт за неделю до релиза, испугавшись “хай-риска” (связка крипты и фиатных денег), несмотря на полгода согласований

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

🌍 Локализация данных: когда законы опережают инфраструктуру

Требование хранить и обрабатывать данные на территории страны часто разбивается о суровую реальность — отсутствие нормальных дата-центров.

Здесь работает принцип "суровость законов компенсируется необязательностью их исполнения":

🔹 Казахстан: Закон о локализации был принят давно, но его игнорировали годами из-за отсутствия инфраструктуры. Регулятор начал закручивать гайки только после того, как в страну зашли крупные облачные провайдеры (Яндекс, MTS Cloud)

🔹 Беларусь: Требование к операторам хранить аудиозаписи всех звонков оказалось технически невыполнимым (не хватало емкостей хранения), поэтому оно так и осталось на бумаге

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

🥊 Споры с аудиторами и синдром вахтера

С регуляторами и аудиторами можно и нужно спорить.

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

Хуже, когда регулятор сидит внутри. Был случай, когда внутренняя безопасность заблокировала критически важный сервис управления компанией, увидев в логах много 403-х ошибок. Безопасники приняли штатную работу RBAC (отказ в доступе неавторизованным) за хакерскую атаку.

Покажите хоть логи, как взломали. А там 403, 403... Ни одного 200-го ответа не дал, но безопасники на это стриггерились и всё заблокировали

🎥 Запускаем серию архитектурных стримов, основанных на реальных кейсах. Сегодня первая встреча!

🗓 18 декабря
⏰ 20:00 GMT+3

На первом стриме разберём настоящий RFP:
платформу автоматизированной обработки RFQ-документов с ИИ-модерацией, чат-ботом и BI-аналитикой.

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

👤 Ведущий: Андрей Якушин, Solution Architect и Engineering Manager с 18+ лет в IT (архитектура enterprise-систем, финансы, здравоохранение, cloud: AWS / Azure / GCP).

Это только начало серии. Подключайтесь 🚀