В конце марта 2026 года в мессенджере MAX зафиксирован серьезный технический сбой, из-за которого личные сообщения и видеофайлы отправляются не тем адресатам. Проблема связана с ошибкой логики приложения, когда сообщения попадают случайным людям.
В России обсуждается законопроект, обязывающий подтверждать финансовые операции через национальный мессенджер Max.
И это приложение на котором хотя завязать банки, госуслуги и тд. Как тут не ругаться?
Вот статья 65% разработчиков пишут код с ии. Может это в РФ 10% юзают ии. А так по сути да до недавнего времени модели были больше как stack overflow без хейта. Сейчас что-то более менее нормальное стало. Мне нужно было накатить патч на файлы озвучки так как игру обновили и файлы изменили. Codex отказался делать скала что опасно и сломаются файлы. Пришлось самому патчить файлы озвучки. Что бы игру не крашили.
Ну да режется именно сигнатура/класс TLS-трафика (DPI). Самое тупое: я не поднимал никакой VPN, это мои сервисы под тесты и портфолио (Zabbix/Grafana/Prometheus) из-за фильтрации я банально не могу скинуть сылку на них ибо без обхода они не грузятся. Покупай дорогие впс в РФ. Вместо дешевых в ЕС.
curl.exe -k --http1.1 `
-o NUL `
-w "ZBX HTTPS:%{http_code} BYTES:%{size_download} TIME:%{time_total}`n" `
https://zbx.landistack.ru/assets/styles/blue-theme.css?1770977244
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
4 322k 4 16070 0 0 2170 0 0:02:32 0:00:07 0:02:25 0
А если “подменить” легитимный домен (SNI/Host) на ya.ru через --resolve (IP тот же), то всё качается полностью и быстро.
curl.exe -k --http1.1 `
>> --resolve ya.ru:443:146.19.207.107 `
>> -o NUL `
>> -w "YA HTTPS:%{http_code} BYTES:%{size_download} TIME:%{time_total}`n" `
>> https://ya.ru/assets/styles/blue-theme.css?1770977244
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 322k 100 322k 0 0 627k 0 --:--:-- --:--:-- --:--:-- 628k
YA HTTPS:200 BYTES:330630 TIME:0.514245
Да, согласен — “про Дурова” это скорее фигура речи/мем, прямой связи с подсетями ТГ я не доказываю. Просто дежавю: в 2018, когда шла история с требованием ключей/доступа к шифрованию, РКН тоже “стрелял дробью” — под раздачу улетали Google/AWS и куча сторонних сервисов, потому что блокировали/фильтровали не точечно. Сейчас ощущение похожее, темболее после новости о блокировке телеграм, только вместо “в лоб” делают шейпинг (те самые 16к), из-за чего диагностика превращается в ад: формально 200 OK, а по факту после первых килобайт всё замирает.
Дуров опять прикалывается над РКН: вместо нормальной блокировки — «умное» замедление. Самая боль в том, что curl честно показывает 200 OK, иногда даже успевает скачать кусок/мелкие файлы, а в браузере — “пару килобайт и всё” (висит, NET_RESET/вечная загрузка). В итоге несколько часов улетает на проверку nginx/сертов/HTTP2, хотя с сервером всё нормально.
Кратко как диагностировал (на файле ~1 МБ):
Проверка по HTTP/80 и HTTPS: curl получает 200, загрузка стартует.
Дальше типичный симптом шейпинга: после первых килобайт (порядка десятков КБ) поток резко замедляется почти в ноль/зависает без явного обрыва.
Исключил DNS: curl --resolve домен:порт:IP (IP принудительно, но Host/SNI остаётся доменным) — поведение то же. Значит проблема не в DNS и не в сервере, а в фильтрации/шейпинге по домену/классу трафика на пути.
Вот поэтому это особенно мерзко: формально “доступ есть” (200), а по факту пользоваться невозможно.
И отдельно: за что “спецы” в РКН получают зарплату — непонятно. Проверять, что именно они ломают/замедляют, они вообще не думают? Нормального тестирования у себя (регресс, выборка популярных сервисов, контрольные скачивания больших файлов, проверка HTTP/HTTPS, домены/поддомены, разные провайдеры) — судя по результату, нет. Они “поумнели” после истории с деградацией YouTube: не рубить в лоб, а душить так, чтобы выглядело как “у вас проблемы”. Думают, что супергерои. Только YouTube — это одна инфраструктура, а Дуров, как обычно, стебётся над “гениями”, а побочкой летит всё подряд — включая рабочие сервисы и репозитории.
Это всё можно сделать на фрилансе за ~2. Главное найти того кто все проверит.
Каркас и инфраструктура. Нанимается человек, который подбирает архитектуру и структуру проекта, поднимает Git-репозиторий, настраивает dev и prod окружения, делает CI/CD, выносит секреты в env или values. На том же Kwork за 500–2000 ₽ такие задачи закрывают регулярно.
CRM под конкретные задачи бизнеса. Нанимается фуллстек, который делает CRM под реальные бизнес-процессы, с простым и понятным интерфейсом, без перегруженного UI, только с нужным функционалом и необходимыми интеграциями. Bitrix, Vtiger, AmoCRM, Zoho — перегруженные и неудобные системы. После работы с ними моя жена написала свою CRM с простым интерфейсом, который спокойно осваивает человек 55+ лет.
Настройка сервера. Отдельный специалист настраивает сервер, делает резервное копирование, настраивает workflow, при котором раз в неделю проект автоматически разворачивается на новой VPS из резервной копии, после развёртывания запускаются автотесты, проверяется запуск сервисов и доступность приложения, при ошибках отправляются алерты в Telegram, после завершения проверок VPS обнуляется и удаляется, настраивается мониторинг с алертами в Telegram, настраивается PHP, включая OPcache и конфиги, настраивается база данных под реальные объёмы. Это не вау-эффект и не космос, для нормальных специалистов это рутина, у них уже есть заготовки workflow, Ansible-ролей и Docker-конфигураций, которые просто адаптируются под проект. А не ситуация, когда сервер с 12 GB RAM, а база работает на 512 MB, при индексах на 1.4 GB.
Безопасность. Отдельно нанимается специалист для проверки и закрытия уязвимостей.
Рост базы данных. При росте базы до ~10 GB анализируются медленные запросы, оптимизируются запросы и индексы.
ИИ зло. Как и IDE с автоподстовлением кода. Не зря в яндексе нужно код писать на доске, а не в IDE, это горантия того, что человек понимает, а не просто вставляет.
Я вообще не понимаю автора. В чем смысл его рассуждений?
Если блокируют сам протокол, что, кстати, не так, то как тогда финтеху работать? Перехват пакетов по Wi-Fi и так далее никуда не исчезает.
Что мешает купить VPS в Беларуси и оттуда прокинуть туннель в Германию или любую другую страну? Окей, допустим, сценарий такой: «грохнут» все VPS. Тогда можно найти родственников, поставить у них одноплатный ПК и прокинуть туннель с динамическим IP или Купить выделеный.
Если речь идет про мобильный интернет и белые списки, то пулы уже давно разделяют. И если у вас нет прямого доступа к белым пулам, то все, дальше это уже комедия.
Кодинг Junior. В мечтах: задача на два часа - сделана за два часа. Тимлид объяснил, помог разобраться. Код прошёл ревью. Все довольны, тикет закрыт.
В реальности. Тимлид: «Спроси у GPT». GPT: «Вот рабочий пример». Рабочий - да. Безопасный - нет.
Пример «рабочего» кода из интернета:
Чиним права. Плохой пример. Ну на php контейнер docker.sock тоже плохой совет был.
Php
<?php
$user = $_GET['user'];
$cmd = "sudo -u root useradd " . $user;
echo shell_exec($cmd);
chmod("/var/www", 0777);
?>
Поздравляем. Удалённое выполнение команд, root-доступ, 777 на проде. Можно сразу открывать хост всему интернету.
Джун идёт на Stack Overflow. Ответ: «Недостаточно данных». Следом: «Где лог?» — «Покажи ошибку» - «А что в error.log?» - «А ты вообще воспроизводил проблему?» Вопросов больше, чем ответов. Самооценка падает быстрее, чем сервер под нагрузкой.
Постепенно приходит понимание: копипаста - не решение, GPT - не тимлид, root - не костыль, а безопасность - не опция. И начинается настоящее обучение: log, log, log, чтение ошибок, минимальные права, воспроизведение проблемы, понимание, а не магия.
Кодинг сеньора. В мечтах: чистая архитектура, понятные функции, предсказуемый результат.
В реальности - это ещё и легаси. Открываешь error.log, а там бесконечные PHP Warning. Где фатал? Его просто не видно за шумом. Почему не работает? Null прилетел из запроса, строку забыли взять в кавычки, конфиг на проде отличается от локального.
Где документация? В голове Васи, которого уволили. Тесты устарели. В коде комментарий «потом разобраться». Задача «на полчаса» идёт уже третий час.
Один фикс тянет за собой два, а те - ещё три фикса. Рефактор откладывается «до лучших времён». Деплой в пятницу был плохой идеей.
В итоге просто вставляем log, log, log, log прямо в код и ищем, где именно всё ломается.
Галлюцинирующий LMM-агент обычно поддаётся быстрой коррекции: контроль можно реализовать через workflow - с этапами валидации, факт-чекинга, sanity-проверок, retries и rollback состояния. Сложности начинаются, когда агент функционирует полностью автономно: его сбои и галлюцинации могут накапливаться без внешнего контроля. Однако даже в таком режиме машинный агент остаётся более управляемым, чем человек при утрате критического мышления: человеческое поведение в подобном состоянии плохо прогнозируемо и потенциально опасно, тогда как LMM-агента почти всегда можно оперативно остановить, перезапустить, откатить к стабильному состоянию или переинициализировать
Спор строится на ложном предположении, что LLM пишет плохой код, а люди исключительно хороший. На практике это не так. Люди регулярно пишут плохой код, в том числе целыми командами. Я лично видел CRM, над которой работала профессиональная команда: таймаута в 15 минут перестало хватать для выполнения одного скрипта, процесс просто убивало. После снятия ограничения стало видно реальное качество реализации. В проект вложили более 30 миллионов с 2016 года. Отдельная проблема это так называемые "бумажные сеньоры", люди с громкими титулами и резюме, но без реальной инженерной глубины. Они принимают архитектурные решения, не понимая последствий, тиражируют плохие практики и формируют культуру, в которой посредственный код считается нормой. Более того, у людей бывает и системный сговор: решения проталкиваются, код-ревью формальное, архитектурные ошибки закрепляются годами. Так что сравнивать нужно не «идеального человека» с «реальной LLM», а реальные системы с реальными людьми. Вывод простой: чтобы проект не деградировал, нужно либо иметь действительно надёжного человека, который глубоко разбирается в коде и проекте и несёт за него персональную ответственность, либо тащить всё соло и контролировать качество самостоятельно
Ключевая разница между классическим системным администратором и DevOps не в инструментах, а в реакции на сбой. В типичной админской модели всё просто. Сервис упал, сеть деградировала, АТС перестала отвечать и об этом узнают от пользователя. Через звонок, жалобу или тикет. Инцидент уже произошёл, бизнес уже потерял деньги, реакция начинается постфактум. В DevOps-подходе иначе. Сервис только начал деградировать по метрикам, алерт уже сработал. Причина локализована, исправление внесено до того, как пользователи вообще что-то заметили. В идеале без простоя. Показательный пример из жизни. У моей жены на работе системный администратор с опытом больше 15 лет. При этом алерты на серверы, сайты и АТС настраивал я. Почему? Потому что жена работает в техподдержке и ей надоело узнавать о падениях постфактум, когда пользователи уже недовольны и звонят с проблемой, которая существует не первый час. Я так же строю свои проекты. Мониторинг и алертинг не как опция, а как обязательный слой. Неважно, CRM это, АТС или обычный лендинг. Если сайт лежит и об этом узнают через день, это не мелочь, а провал операционной модели. Лежащий лендинг это потерянные заявки. Лежащая АТС это пропущенные звонки. Отсутствие алертов это не экономия, а отложенные потери. Отдельная история это коробочные сетевые решения. Часто админы по привычке используют Cisco и подобные вендорские устройства. Закрытая экосистема, дорогое железо, минимум гибкости, сложная автоматизация или её отсутствие. При этом те же задачи спокойно решаются сервером с Linux. Маршрутизация, firewall, VPN, балансировка, мониторинг. Дешевле, гибче и полностью под контролем. Поэтому, когда говорят «у нас есть админ, он следит за сетью», всегда возникает один вопрос. Он действительно следит или просто узнаёт о проблемах от пользователей.
Похоже навайбкодили в Max.
В конце марта 2026 года в мессенджере MAX зафиксирован серьезный технический сбой, из-за которого личные сообщения и видеофайлы отправляются не тем адресатам. Проблема связана с ошибкой логики приложения, когда сообщения попадают случайным людям.
В России обсуждается законопроект, обязывающий подтверждать финансовые операции через национальный мессенджер Max.
И это приложение на котором хотя завязать банки, госуслуги и тд. Как тут не ругаться?
Вот статья 65% разработчиков пишут код с ии. Может это в РФ 10% юзают ии. А так по сути да до недавнего времени модели были больше как stack overflow без хейта. Сейчас что-то более менее нормальное стало. Мне нужно было накатить патч на файлы озвучки так как игру обновили и файлы изменили. Codex отказался делать скала что опасно и сломаются файлы. Пришлось самому патчить файлы озвучки. Что бы игру не крашили.
Цели проще. Продавать хламо оборудование на сотни миллиардов. За что отвечают нужные люди.
Вот так вот сын главы ФСБ развил стартап от 5 млн до 150 миллиардов.
Как белые списки и оборудование связано. Например новость фсб исключило Сбербанк из белых списков пока он не закупит нужно оборудование на свои узлы.
По блютузу передавайте.
codex 5.3 как раз окуратнее и заточен больше под кодинг. А 5.4 просто общая модель в которую кусок от codex запихали
Ну да режется именно сигнатура/класс TLS-трафика (DPI). Самое тупое: я не поднимал никакой VPN, это мои сервисы под тесты и портфолио (Zabbix/Grafana/Prometheus) из-за фильтрации я банально не могу скинуть сылку на них ибо без обхода они не грузятся. Покупай дорогие впс в РФ. Вместо дешевых в ЕС.
А если “подменить” легитимный домен (SNI/Host) на ya.ru через
--resolve(IP тот же), то всё качается полностью и быстро.Да, согласен — “про Дурова” это скорее фигура речи/мем, прямой связи с подсетями ТГ я не доказываю. Просто дежавю: в 2018, когда шла история с требованием ключей/доступа к шифрованию, РКН тоже “стрелял дробью” — под раздачу улетали Google/AWS и куча сторонних сервисов, потому что блокировали/фильтровали не точечно. Сейчас ощущение похожее, темболее после новости о блокировке телеграм, только вместо “в лоб” делают шейпинг (те самые 16к), из-за чего диагностика превращается в ад: формально
200 OK, а по факту после первых килобайт всё замирает.Дуров опять прикалывается над РКН: вместо нормальной блокировки — «умное» замедление. Самая боль в том, что
curlчестно показывает200 OK, иногда даже успевает скачать кусок/мелкие файлы, а в браузере — “пару килобайт и всё” (висит,NET_RESET/вечная загрузка). В итоге несколько часов улетает на проверку nginx/сертов/HTTP2, хотя с сервером всё нормально.Кратко как диагностировал (на файле ~1 МБ):
Проверка по HTTP/80 и HTTPS:
curlполучает200, загрузка стартует.Дальше типичный симптом шейпинга: после первых килобайт (порядка десятков КБ) поток резко замедляется почти в ноль/зависает без явного обрыва.
Исключил DNS:
curl --resolve домен:порт:IP(IP принудительно, но Host/SNI остаётся доменным) — поведение то же. Значит проблема не в DNS и не в сервере, а в фильтрации/шейпинге по домену/классу трафика на пути.Вот поэтому это особенно мерзко: формально “доступ есть” (
200), а по факту пользоваться невозможно.И отдельно: за что “спецы” в РКН получают зарплату — непонятно. Проверять, что именно они ломают/замедляют, они вообще не думают? Нормального тестирования у себя (регресс, выборка популярных сервисов, контрольные скачивания больших файлов, проверка HTTP/HTTPS, домены/поддомены, разные провайдеры) — судя по результату, нет. Они “поумнели” после истории с деградацией YouTube: не рубить в лоб, а душить так, чтобы выглядело как “у вас проблемы”. Думают, что супергерои. Только YouTube — это одна инфраструктура, а Дуров, как обычно, стебётся над “гениями”, а побочкой летит всё подряд — включая рабочие сервисы и репозитории.
Это всё можно сделать на фрилансе за ~2. Главное найти того кто все проверит.
Каркас и инфраструктура.
Нанимается человек, который подбирает архитектуру и структуру проекта, поднимает Git-репозиторий, настраивает dev и prod окружения, делает CI/CD, выносит секреты в env или values. На том же Kwork за 500–2000 ₽ такие задачи закрывают регулярно.
CRM под конкретные задачи бизнеса.
Нанимается фуллстек, который делает CRM под реальные бизнес-процессы, с простым и понятным интерфейсом, без перегруженного UI, только с нужным функционалом и необходимыми интеграциями. Bitrix, Vtiger, AmoCRM, Zoho — перегруженные и неудобные системы. После работы с ними моя жена написала свою CRM с простым интерфейсом, который спокойно осваивает человек 55+ лет.
Настройка сервера.
Отдельный специалист настраивает сервер, делает резервное копирование, настраивает workflow, при котором раз в неделю проект автоматически разворачивается на новой VPS из резервной копии, после развёртывания запускаются автотесты, проверяется запуск сервисов и доступность приложения, при ошибках отправляются алерты в Telegram, после завершения проверок VPS обнуляется и удаляется, настраивается мониторинг с алертами в Telegram, настраивается PHP, включая OPcache и конфиги, настраивается база данных под реальные объёмы. Это не вау-эффект и не космос, для нормальных специалистов это рутина, у них уже есть заготовки workflow, Ansible-ролей и Docker-конфигураций, которые просто адаптируются под проект. А не ситуация, когда сервер с 12 GB RAM, а база работает на 512 MB, при индексах на 1.4 GB.
Безопасность.
Отдельно нанимается специалист для проверки и закрытия уязвимостей.
Рост базы данных.
При росте базы до ~10 GB анализируются медленные запросы, оптимизируются запросы и индексы.
Итог.
На рынке избыток специалистов.
Это реальность.
Если ты:
пишешь код
деплоишь через кнопку
чинишь, пока не заработает
но не понимаешь, что реально происходит внутри машины, ты не программист. Ты пользователь IDE с правами администратора.
ИИ зло. Как и IDE с автоподстовлением кода. Не зря в яндексе нужно код писать на доске, а не в IDE, это горантия того, что человек понимает, а не просто вставляет.
Я вообще не понимаю автора. В чем смысл его рассуждений?
Если блокируют сам протокол, что, кстати, не так, то как тогда финтеху работать? Перехват пакетов по Wi-Fi и так далее никуда не исчезает.
Что мешает купить VPS в Беларуси и оттуда прокинуть туннель в Германию или любую другую страну? Окей, допустим, сценарий такой: «грохнут» все VPS. Тогда можно найти родственников, поставить у них одноплатный ПК и прокинуть туннель с динамическим IP или Купить выделеный.
Если речь идет про мобильный интернет и белые списки, то пулы уже давно разделяют. И если у вас нет прямого доступа к белым пулам, то все, дальше это уже комедия.
Зачем использовать Cloud Code на VPS? Разверни проект локально на ПК.
Если у тебя Windows, установи Docker Desktop и запускай проект в WSL.
Убедись, что твой пользователь добавлен в группу, которой принадлежат файлы в примонтированных Docker volume, иначе не будет прав на запись.
В Wsl по умолчанию конектишся не от root. Да и прывакать надо быть не вечный root.
Далее настрой деплой на VPS через GitHub Actions.
Подключайся к серверу не под root, а создай отдельного пользователя, например deploy, и выдай ему необходимые права.
После этого всё будет работать стабильно и предсказуемо.
Ps. Охранник с пятерочки. Я сам только учусь.
Ну капец, на телефоне каждая строка новый параграф. А с пк нормально всё.
Сори за текст как туалетная бумана выше.
Я охранник в пятерочке. В it не бум бум.
Но надежнее с shebang
#!/usr/bin/env bash
Я бы еще добавил. Проверку pipeline
set -euo pipefail
Если df не выполнится — сейчас вы об этом не узнаете.
С pipefail скрипт корректно завершится с ошибкой.
df -h / | tail -1 | while read fs size used avail percent mount; do
Если uptime или awk вернёт ошибку — это будет зафиксировано.
Без pipefail ошибка journalctl может быть замаскирована.
if journalctl ... | grep -q "."; then
Возвращает код 1, если ничего не найдено. В старых версиях bash может завершить скрипт. Потому лучше.
if journalctl --since "10m ago" -p err 2>/dev/null | grep -q "." || false; then
...
fi
А еще лучше сделать так.
#!/usr/bin/env bash
set -Eeuo pipefail
trap 'echo "Ошибка в строке $LINENO" >&2' ERR
Это даст диагностику при падении.
Лучше printf для совместимости. Вместо echo -e
log() {
printf "%s - %b\n" "$(date '+%H:%M:%S')" "$1" | tee -a "$LOG"
}
Ps как с телефона сделать межстрочное растояние меньше?
Кодинг Junior. В мечтах: задача на два часа - сделана за два часа. Тимлид объяснил, помог разобраться. Код прошёл ревью. Все довольны, тикет закрыт.
В реальности. Тимлид: «Спроси у GPT». GPT: «Вот рабочий пример». Рабочий - да. Безопасный - нет.
Пример «рабочего» кода из интернета:
Чиним права. Плохой пример. Ну на php контейнер docker.sock тоже плохой совет был.
Php
<?php
$user = $_GET['user'];
$cmd = "sudo -u root useradd " . $user;
echo shell_exec($cmd);
chmod("/var/www", 0777);
?>
Поздравляем. Удалённое выполнение команд, root-доступ, 777 на проде. Можно сразу открывать хост всему интернету.
Джун идёт на Stack Overflow. Ответ: «Недостаточно данных». Следом: «Где лог?» — «Покажи ошибку» - «А что в error.log?» - «А ты вообще воспроизводил проблему?» Вопросов больше, чем ответов. Самооценка падает быстрее, чем сервер под нагрузкой.
Постепенно приходит понимание: копипаста - не решение, GPT - не тимлид, root - не костыль, а безопасность - не опция. И начинается настоящее обучение: log, log, log, чтение ошибок, минимальные права, воспроизведение проблемы, понимание, а не магия.
Кодинг сеньора. В мечтах: чистая архитектура, понятные функции, предсказуемый результат.
В реальности - это ещё и легаси. Открываешь error.log, а там бесконечные PHP Warning. Где фатал? Его просто не видно за шумом. Почему не работает? Null прилетел из запроса, строку забыли взять в кавычки, конфиг на проде отличается от локального.
Где документация? В голове Васи, которого уволили. Тесты устарели. В коде комментарий «потом разобраться». Задача «на полчаса» идёт уже третий час.
Один фикс тянет за собой два, а те - ещё три фикса. Рефактор откладывается «до лучших времён». Деплой в пятницу был плохой идеей.
В итоге просто вставляем log, log, log, log прямо в код и ищем, где именно всё ломается.
Это не echo Hello World.
Галлюцинирующий LMM-агент обычно поддаётся быстрой коррекции: контроль можно реализовать через workflow - с этапами валидации, факт-чекинга, sanity-проверок, retries и rollback состояния. Сложности начинаются, когда агент функционирует полностью автономно: его сбои и галлюцинации могут накапливаться без внешнего контроля. Однако даже в таком режиме машинный агент остаётся более управляемым, чем человек при утрате критического мышления: человеческое поведение в подобном состоянии плохо прогнозируемо и потенциально опасно, тогда как LMM-агента почти всегда можно оперативно остановить, перезапустить, откатить к стабильному состоянию или переинициализировать
Спор строится на ложном предположении, что LLM пишет плохой код, а люди исключительно хороший. На практике это не так. Люди регулярно пишут плохой код, в том числе целыми командами.
Я лично видел CRM, над которой работала профессиональная команда: таймаута в 15 минут перестало хватать для выполнения одного скрипта, процесс просто убивало. После снятия ограничения стало видно реальное качество реализации. В проект вложили более 30 миллионов с 2016 года.
Отдельная проблема это так называемые "бумажные сеньоры", люди с громкими титулами и резюме, но без реальной инженерной глубины. Они принимают архитектурные решения, не понимая последствий, тиражируют плохие практики и формируют культуру, в которой посредственный код считается нормой.
Более того, у людей бывает и системный сговор: решения проталкиваются, код-ревью формальное, архитектурные ошибки закрепляются годами. Так что сравнивать нужно не «идеального человека» с «реальной LLM», а реальные системы с реальными людьми.
Вывод простой: чтобы проект не деградировал, нужно либо иметь действительно надёжного человека, который глубоко разбирается в коде и проекте и несёт за него персональную ответственность, либо тащить всё соло и контролировать качество самостоятельно
Ключевая разница между классическим системным администратором и DevOps не в инструментах, а в реакции на сбой.
В типичной админской модели всё просто. Сервис упал, сеть деградировала, АТС перестала отвечать и об этом узнают от пользователя. Через звонок, жалобу или тикет. Инцидент уже произошёл, бизнес уже потерял деньги, реакция начинается постфактум.
В DevOps-подходе иначе. Сервис только начал деградировать по метрикам, алерт уже сработал. Причина локализована, исправление внесено до того, как пользователи вообще что-то заметили. В идеале без простоя.
Показательный пример из жизни. У моей жены на работе системный администратор с опытом больше 15 лет. При этом алерты на серверы, сайты и АТС настраивал я. Почему? Потому что жена работает в техподдержке и ей надоело узнавать о падениях постфактум, когда пользователи уже недовольны и звонят с проблемой, которая существует не первый час.
Я так же строю свои проекты. Мониторинг и алертинг не как опция, а как обязательный слой. Неважно, CRM это, АТС или обычный лендинг. Если сайт лежит и об этом узнают через день, это не мелочь, а провал операционной модели. Лежащий лендинг это потерянные заявки. Лежащая АТС это пропущенные звонки. Отсутствие алертов это не экономия, а отложенные потери.
Отдельная история это коробочные сетевые решения. Часто админы по привычке используют Cisco и подобные вендорские устройства. Закрытая экосистема, дорогое железо, минимум гибкости, сложная автоматизация или её отсутствие. При этом те же задачи спокойно решаются сервером с Linux. Маршрутизация, firewall, VPN, балансировка, мониторинг. Дешевле, гибче и полностью под контролем.
Поэтому, когда говорят «у нас есть админ, он следит за сетью», всегда возникает один вопрос. Он действительно следит или просто узнаёт о проблемах от пользователей.