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

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

Но если мы видим в этом потоке что-то, что с нашей точки зрения, действительно заслуживает внимания, мы приносим это сюда для друзей и коллег. Мы — это инженеры Фланта и Экспресс42, компаний, которые стояли у истоков DevOps в России.

Надеемся, что Девопс Дефлопе станет самым полезным девопс-каналом в вашей ленте!

Вышел первый серьёзный отчёт State of GitOps 2025 — исследование 660 команд о том, как GitOps работает в реальности.

Главное открытие неутешительное. Большинство команд думают, что делают GitOps, но на самом деле, кажется, просто коммитят скрипты в Git. 60% до сих пор используют императивную конфигурацию вместо декларативной.

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

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

Интересный момент про медленный code review. Он указан как одна из основных причин, почему команды откатываются к ручным изменениям через kubectl. Ну а это подрывает принципы GitOps, потому что Git перестает быть единственным источником истины.

А вы с какими проблемами при использовании GitOps сталкиваетесь?

В свежем выпуске подкаста «DevOps Дефлопе» болтаем про пет-проекты:

- Любовь Павла к сбору информации и парсинг Steam, а также его бот для конференций.
- Зачем Сергей написал приложение под Android и как запускал Quake III на тормозном рабочем компе.
- Как Виталий получил опыт деплоя лямбда-функций через Terraform и сделал себе погодную станцию.

А ещё вспоминаем рождение NGINX и рассуждаем, зачем вообще нужна работа, за которую не платят.

Слушать:
на удобной площадке
на YouTube

Пока все увлечённо обсуждают очередные обновления от OpenAI и Anthropic, GitLab неделю назад запустил в публичную бету свою платформу AI-агентов.

Вместо очередного чат-бота GitLab создаёт платформу GitLab Duo, где AI-агенты работают как полноценные члены команды.

По сути, AI-агент выступает как младший разработчик, который требует проверки от сеньора. Благодаря тому, что GitLab объединяет задачи, код и CI/CD в одной системе, его агенты работают с полным контекстом проекта. Так агенты получают преимущество перед внешними AI-инструментами с их ограниченным контекстом.

А ещё можно создавать и подключать собственных агентов под свои задачи и автоматизировать цепочки действий через Flows (например, анализ инцидентов или миграции пайплайнов)

Правда, Gitlab Duo Agent Platform доступна только в бете для Premium/Ultimate клиентов gitlab.com и self-managed инсталляций, но документация, API и SDK уже есть в открытом доступе.
Направление логично — превратить GitLab из платформы для DevOps в DevOps-платформу с искусственным интеллектом.

Какие задачи вы уже делегировали AI-агентам?)

Чтобы каждая реплика LLM приходила за миллисекунды и не разоряла бюджет на GPU, инфраструктура должна быть столь же умной, как сама модель.

Сегодня для этого есть два зрелых Open Source-движка — vLLM и SGLang. Оба уже служат базой для корпоративных продуктов Red Hat и LMSYS, поэтому технологический риск минимален. Ниже — как каждый из них помогает бизнесу экономить и в каких сценариях их применять.

Почему это важно прямо сейчас? Стоимость GPU-минут растёт, а объём запросов к моделям увеличивается экспоненциально, что напрямую бьёт по TCO AI-инициатив.

vLLM — максимум пропускной способности

• PagedAttention устраняет 60-80% фрагментации памяти через блочные таблицы (как виртуальная память в ОС), давая до ×24 больше throughput, чем Hugging Face Transformers.
• Continuous Batching обрабатывает запросы по шагам генерации. Таким образом быстрые не ждут медленных, снижается latency и пропадает простой GPU (〜x23 прирост пропускной способности).
• Совместимость с OpenAI API позволяет мигрировать SaaS-сервисы без переписывания клиентского кода.

Именно vLLM лежит в основе Red Hat AI Inference Server для OpenShift, так что решение готово к production-кластерам. А ещё LMSYS сократил

парк

GPU на 50 %, одновременно увеличив число обслуживаемых запросов в 2–3 раза после миграции на vLLM.

SGLang — это экономия на связанных запросах

• RadixAttention строит древовидную структуру для переиспользования KV-кеша между запросами с общими префиксами. Если пользователь ведёт диалог, SGLang автоматически переиспользует уже вычисленные части контекста, ускоряя цепочки вызовов до ×5 и снижая вычислительные затраты.
• Строго заданный вывод: можно жёстко задать JSON-схему или грамматику, избегая дорогой поствалидации.
• Оптимальный выбор для диалоговых агентов, RAG-конвейеров и других сценариев, где соседние запросы делят контекст и важна точная структура ответа.

Как выбрать
Если ваша нагрузка — множество независимых коротких запросов и вы заменяете коммерческий API, ставьте vLLM: он максимально нагружает GPU и обеспечивает низкую задержку. Когда же важны длинные диалоги, строгий формат ответа или повторное использование контекста, применяйте SGLang, который экономит вычисления там, где другие их дублируют.

Итого
Разверните оба движка в одной инфраструктуре: vLLM — на «горячем» пути API для массовых запросов, SGLang — в сервисах с многошаговыми генерациями. Так вы получите быстрые ответы при минимальной стоимости GPU; именно то, что нужно бизнесу здесь и сейчас.

Традиционные WAF эффективны против классических веб-атак, но плохо справляются с современными угрозами API. Рассмотрим различия между WAF и WAAP подходами к защите.

В I квартале 2025 г. количество DDoS-атак на API в России выросло на 74% по сравнению с аналогичным периодом 2024 г. (данные StormWall), а традиционные WAF их попросту не видят. Хакеры больше не ломают двери, они используют правильные ключи в неправильном порядке.

Ваш WAF работает как охранник 90-х: проверяет документы по списку «плохих слов», но не понимает, зачем посетитель пришёл. Атакующий делает 1000 валидных запросов к /api/user/profile за секунду? WAF молчит, ведь каждый запрос синтаксически корректен. И атакующий спокойно вытаскивает персональные данные миллионов пользователей через некорректно защищенный эндпойнт.

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

Web Application and API Protection не ищет «вредоносные» запросы. Вместо этого он изучает нормальные паттерны каждого API и детектирует аномалии поведения:

• ML-анализ в реальном времени.

Система знает, что пользователь обычно делает 3-5 запросов в минуту, а не 300

• Контекстное понимание workflow.

WAAP видит последовательности вызовов API и выявляет попытки обойти предполагаемые рабочие процессы.

• Автоматическое обнаружение API.

Мониторинг сетевого трафика находит «теневые» эндпоинты, о которых забыли документировать.

WAAP решает главную болевую точку CI/CD. С ним больше не нужно вручную настраивать правила для каждого нового эндпоинта. Выкатили новую версию API? WAAP автоматически анализирует трафик и настраивает защиту.

Есть и бонус для разработчиков. Вместо "security review" на две недели получаете автоматическую защиту с первого деплоя. Команда безопасности видит реальное поведение API, а не гадает на кофейной гуще по коду.

Как начать
• Аудит API-ландшафта. Соберите все эндпоинты в единый каталог с OpenAPI-спецификациями
• Стандартизация. Унифицируйте аутентификацию и error handling (WAAP лучше работает с консистентной архитектурой)
• Correlation ID. Добавьте во все запросы для отслеживания многоступенчатых атак
• Безопасность как код. Внедрите этот подход в API-фреймворки и CI/CD пайплайны

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

Внедряйте сейчас, пока атакующие не обошли ваши текущие «правила безопасности».

В начало поста ←

«Observability никому не нужно»

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

В этом выпуске Виталий Лихачёв, автор канала «Kubernetes и кот Лихачева», и Евгений Бастрыков, тимлид команды разработки Prom++, разберут:
- почему 90 % ваших алертов — мусор;
- как eBPF и OpenTelemetry пытаются спасти мир;
- можно ли получать метрики из… чего угодно (спойлер: да);
- почему «наблюдаемость» — это не про слежку, а про то, чтобы не сойти с ума.

И главное: кому вообще нужно это Observability, если Чак Норрис пишет код без багов?

Слушать:
на удобной площадке
YouTube
Яндекс Музыка

Помните, Apple представила открытые проекты container и containerization для нативной контейнеризации на macOS? Написано на Swift, оптимизировано для Apple Silicon и вызывает больше вопросов, чем восторга.

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

Вместо привычной модели с shared kernel, Apple создают отдельную ВМ для каждого контейнера через Virtualization.framework. Обещают sub-second startup и hypervisor-level изоляцию, но на практике работает только на Apple Silicon с macOS 26. Экосистемы никакой, ни сompose, ни оркестрации.

Оба проекта  находятся в активной разработке. macOS 26 выйдет только в сентябре-октябре, так что сейчас это скорее preview для энтузиастов.

Мы так и не смогли понять, зачем нужен эппловский container, если уже есть docker-desktop и lima с привычным докером. Непонятно, будет ли работать в docker/containerd то, что сделано в container.

Возможно, это заготовка под будущие задачи Apple в области cloud/edge computing. А может, просто очередной эксперимент, который останется нишевым инструментом для узкого круга задач на macOS.

DevOps Deflope теперь и на Spotify.
А все (реально все, даже RSS-фид для олдскульных) другие сервисы найдёте на Mave.
Будем рады вашим звёздам, сердечкам и отзывам. Stay tuned!

Книги от Google по SRE весьма полезны, но не у всех есть время прочесывать 1000+ страниц принципов и философии. Автор с Medium, Magsther, решил эту проблему — он прочитал всю трилогию и превратил массив теории в 100 практических уроков.

Каждый урок рассчитан на самостоятельное изучение. Есть и про философию, например, “Error budgets are the reliability currency”; и про практические правила — “No SLO? No reliability”.

Нет регистрации, рекламы или paywall. Ну круто же :)

Тем не менее, делимся и книгами, по которым и сделаны 100 уроков:

• Site Reliability Engineering (2016),
• The Site Reliability Workbook (2018),
• Building Secure & Reliable Systems (2020)

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

«Хилы, танки и дамагеры DevOps» — каждый понимает DevOps по-своему. В новом выпуске DevOps Deflope узнаете:

• Почему DevOps-инженеры сравнивают себя с героями WoW?
• Как пайплайны помогают печь круассаны?
• Зачем DevOps’у лезть в архитектуру приложений?
• Чему учат в магистратуре по DevOps и можно ли его считать методологией?

Гость выпуска Константин Дипеж — создатель магистратуры по DevOps, доцент МФТИ и автор канала DeusOps.

Слушайте:
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте

Новый выпуск — и он про безопасность!

В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает:

• что будет, если вообще забить на безопасность;
• почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF;
• правда ли, что хакеры теперь умнее нас из-за ИИ;
• как внедрить безопасность, чтобы тебя не возненавидели все разработчики.

Слушать →
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте

Наткнулись на kubesec-diagram — интерактивную карту угроз Kubernetes, созданную внутри Telenor Norway. И знаете что? Она реально хорошая :)

Это интерактивная SVG-схема, визуализирующая поверхность атаки Kubernetes-кластера. Всё заточено под on-prem, так что для облачных K8s-кластеров и managed-сервисов может быть не так актуальна. Но, в целом, диаграмма может помочь, когда нужно быстро разобраться в security-контексте K8s или объяснить джуну, почему RBAC — это не просто галочка в чек-листе.

Внутри живая схема с кликабельными элементами. Тыкаете на "Container Process", получаете детали про PodSecurityContext, syscall restrictions и runtime enforcement. В разделе RBAC наглядно показана работа role bindings и опасность группы “system:masters”.

Думаем, что инструмент может быть полезен для DevOps/SRE-инженеров как минимум в двух основных сценариях: обучение новичков и быстрый аудит во время инцидентов. Да, большинство информации можно найти в CIS Benchmark или официальной документации K8s, но когда нужно быстро освежить тему или показать коллеге связь между компонентами — почему нет?

Диаграмма местами перегружена деталями, и для продакшена все равно придется изучать каждый компонент отдельно. Но как starting point для понимания attack surface в кластере — вполне годится. Ещё можно сесть, покопаться и найти что-то новое.

Проект активен, последнее обновление — v9 от августа 2025 года. Это полезный вспомогательный инструмент, но не истина в последней инстанции.

Сохраните в закладки для командных обсуждений архитектуры, но, всё же, для полноценного аудита полагаться на специализированные средства, такие как kube-bench, kubeaudit или Falco.

Проект на GitHub: github.com/kubesec-diagram/kubesec-diagram.github.io

Быстро потестировать etcd или поковырять containerd без поднятия локального кластера? Собрали браузерные песочницы, где можно экспериментировать с инфраструктурным софтом без танцев вокруг Docker Desktop и minikube.

1. Etcd Playground — для тех, кто хочет понять мозг Kubernetes
Интерактивная песочница с полноценным (но, ясное дело, учебным) кластером etcd из трёх нод.

2. Kubernetes Playground — браузерная площадка с готовым многоузловым кластером Kubernetes
Кластер развёрнут через kubeadm с возможностью выбора контейнерного рантайма и сетевого плагина. Можно экспериментировать с настройками, отлаживать манифесты и тренироваться в администрировании.

3. Nerdctl Playground — containerd с человеческим лицом
Площадка позволяет работать с containerd через Docker‑совместимый CLI, который упрощает работу по сравнению с нативным ctr. Можно изучать namespaces, snapshotter’ы и жизненный цикл контейнеров без установки локального рантайма.

4. KodeKloud Playgrounds — готовые среды под задачу
Предварительно настроенные среды под конкретные курсы (Terraform, Docker, K8s, Ansible). Не нужно ничего поднимать, остаётся только выполнять задания.

5. LabEx — тренажёр с дорожной картой
Пошаговое обучение с автоматической проверкой заданий. Много практических сценариев от базового Linux до сложных тем в K8s и Cloud.

6. Helm Playground — песочница для Helm-чартов
Позволяет экспериментировать с шаблонами, values и структурой чарта, сразу видя итоговые YAML-манифесты. Удобно для быстрой проверки идей и отладки шаблонов.

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

Используете что‑то интересное для экспериментов с Kubernetes и containerd? Пишите в комментариях :)

4 декабря в Москве пройдёт Kuber Conf от Ассоциации облачно-ориентированных технологий.

Флант, Yandex Cloud и VK Cloud создают АОТ, первую в России некоммерческую организацию для развития Cloud Native-технологий вне вендоров. И сразу делают конференцию, чтобы собрать всех, кто работает с Kubernetes и облаками.

На конфе представители ассоциации расскажут о проекте. Зачем всё это нужно и что хочется делать: стандартизировать компетенции, поддерживать Open Source, объединить сообщество.

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

Хотите стать спикером? Если работали с чем-то новым в Kubernetes, внедряли интересные решения в облаках или решали нетривиальные задачи — расскажите об этом. Рабочий опыт, сложные проблемы, даже провалы (они самые интересные и полезные). CFP ещё открыт.

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

Приходите, будет классно. Давно пора собраться и сделать что-то большое вместе.

До встречи 4 декабря!

ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом.

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

ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе.

Продукт уже работает для пользователей Kubernetes, Helm и GitOps.

Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит.

Источник — пост Alexis Richardson на LinkedIn.

Нельзя так просто взять и спарсить 150 тысяч вакансий… Или можно?

Можно. Именно это сделал автор проекта TrueIndex, чтобы составить альтернативный TIOBE рейтинг, который показывал бы картину спроса на технологии в России.

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

TrueIndex пошёл от обратного и взял не запросы, а вакансии. Парсер собирает данные с HeadHunter и Habr Career, анализируя сотни тысяч объявлений. На их основе он считает статистику по языкам, фреймворкам, базам данных и другим технологиям, которые упоминаются в требованиях.

Первый же срез данных показал неожиданную картину. Технологии, специфичные для российского рынка (например, 1С), оказываются в топе по спросу, хотя в TIOBE их вообще нет, потому что за границей о них не знают. Языки, которые все считают устаревшими, спокойно держатся в топ-10 по количеству вакансий. А что-то вроде Fortran и Assembly из международных рейтингов в массовом найме практически не встречается.

Сейчас TrueIndex собирает данные с HeadHunter и Habr Career, ежемесячно обновляет рейтинг и постепенно расширяет набор метрик.

Зачем это всё? Если ты джун, рейтинг помогает увидеть, какие технологии дают больше всего «входных билетов» в профессию и где спрос не ограничивается одиночными вакансиями. Если ты мидл или сеньор — это удобный способ понять, в какой стек имеет смысл вкладываться, чтобы оставаться востребованным на российском рынке.

Ну а дальше можно просто зайти на trueindex.ru и посмотреть на актуальный рейтинг своими глазами.

Kuber Conf уже завтра, но вы успеваете запрыгнуть.

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

• Как мы строили платформу деплоя в Т.
Послушаем про опыт построения универсальной платформы деплоя на базе OAM и KubeVela. Основная идея — вынести сложность конфигурации инфраструктуры и взаимодействия с Kubernetes на сторону платформы, а разработчикам дать простой и удобный интерфейс для описания приложений. Отдельный плюс: платформа берёт на себя вопросы EoL и миграций, снижая необходимость в бесконечных согласованиях и ручных договорённостях с командами.

• Vitastor и Kubernetes: есть ли жизнь на Марсе. Посмотрим, как интегрировать распределённую СХД через CSI и что там с производительностью в реальных условиях.

• Обучаем LLM по клику: платформа распределённого обучения на HGX. Доклад про то, как в Avito строили MLOps-инфраструктуру для обучения LLM на множестве узлов в рамках платформы Aviflow. Нам расскажут, чем обучение LLM отличается от «обычного» ML, какие технологии нужны для распределённого обучения, и как обернуть это в удобный сценарий. А также и о самом железе (HGX), и его нюансах эксплуатации.

Ещё два доклада будут от нас:
• А вы точно уверены в SLA своего кластера Kubernetes? Владимир Гурьянов из Deckhouse Observability разберёт, почему метрики в состоянии покоя не показывают реальную картину и как правильно тестировать доступность кластера. Плюс практический чеклист для измерения SLA.

• Не Talos единым: как ограничения научили нас ставить Kubernetes поверх любой операционной системы. Денис Романенко из Deckhouse Core покажет, как автоматизировать развёртывание Kubernetes поверх любой ОС, когда современные K8s-дистрибутивы недоступны или не подходят.

Днём слушаем доклады, вечером общаемся на афтерпати. Конфа уже послезавтра, наша редакция тоже там будет.

Когда игровой планировщик оказался лучше для серверов Meta*

Meta запустила на своих production-серверах планировщик SCX-LAVD. Казалось бы, ну планировщик и планировщик. Но фишка в том, что его изначально разрабатывали для портативной игровой консоли Valve Steam Deck. То есть штука для карманного девайса теперь управляет дата-центрами одной из крупнейших IT-компаний мира.

SCX-LAVD — планировщик с учётом критичности задержек. Его создала консалтинговая компания Igalia по контракту с Valve специально для Steam Deck.

Инженеры Meta решили протестировать его на больших серверах. Результат оказался настолько хорошим, что Meta сделала SCX_LAVD планировщиком по умолчанию для своего парка серверов, который работает с различным оборудованием и сценариями использования. Оказалось, что даже на серверах с большим количеством CPU и памяти, LAVD прекрасно справляется с балансировкой нагрузки между CCX/LLC.

На конференции Linux Plumbers Conference в Токио инженеры Meta выступили с презентацией «Как заставить планировщик Steam Deck работать на больших серверах».

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

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

Иногда лучший инструмент приходит оттуда, откуда его совсем не ждали.

Источник: phoronix.com
*Meta признана экстремистской организацией и запрещена в РФ.

2025 год был... интересным. AI прилетел во все возможные продукты (и невозможные тоже), Kubernetes продолжал внедряться в работу с завидной настойчивостью, а количество инструментов для мониторинга выросло настолько, что теперь нужен мониторинг для мониторинга мониторинга.

Вы весь год тушили пожары в production, разбирались с упавшими подами в 3 часа ночи, оптимизировали то, что «и так работает», и объясняли разработчикам, почему нельзя просто «добавить больше памяти». И знаете что? Вы молодцы. Серьёзно.

Что мы вам желаем на 2026 год:
• Чтобы ваши дашборды всегда были зелёными. Ну или хотя бы желтыми. Красный — только для новогодних украшений.
• Чтобы CI/CD pipeline не падал, ни до merge, ни после. Потому что находить баги в production — это не та адреналиновая активность, которую мы выбирали.
• Чтобы документация была актуальной. Комментарий здесь мы даже не смогли придумать.
• Чтобы технический долг рос медленнее, чем зарплата. Хотя бы процентов на 10.

Желаем вам классных проектов, где можно применить то, что давно хотелось попробовать. Спасибо, что читаете нас.

P.S. Не забудьте проверить бэкапы перед праздниками. Нет, серьёзно. Проверьте.

— Редакция