#aws #aurora #rds #troubleshooting
Ко мне снова обратились с привычной проблемой: AWS, есть Aurora MySQL 3.*, большая нагрузка по кверям, увеличили инстанс, добавили CPU и памяти, даже меняли IOPS - но тормоза не ушли.
Особенно заметно на пиковых нагрузках, когда в систему летят десятки тысяч инсертов в секунду.
Знакомая история, которая всегда начинается с "мы уже всё перепробовали" и заканчивается у моего терминала.
Таска говно - впарить лоху (мне).
Не, ну ладно, зарплата сама себя не отработает, поехали разбираться.
Делаю привычное
Коммиты висят по 50-100 мс, хотя дисковая подсистема вроде бы не жалуется.
Первое, что приходит в голову: а чо там, а чо, давайте смотреть на sync_binlog.
Сука.
Бинлог включен. Синхронный.
Каждый коммит ждёт фсинка на диск.
На Aurora MySQL 3.x, где кто-то раньше включил Enhanced Binlog (по дефолту он выключен, но у нас был исторически включён).
Вспоминаю, что на этом проекте был Дебезиум. Вроде бы.
Ладно, зацепка, иду в поиск.
Поднимаю историю по слаку, страницам RFC/PoC в Confluence.
Года три назад у нас был активный конвейер CDC на Debezium - реплицировали данные в Snowflake для аналитики.
Потом проект закрылся, команда разошлась, а инфраструктура осталась.
Кто-то выключил Debezium, кто-то отключил коннекторы, но binlog почему-то остался включённым.
"На всякий случай", "вдруг понадобится", "не трогай, оно работает".
Ну или девопс забыл🤡 (а девопс там был я, фить-ха! )
Только вот работает оно медленно. Каждый INSERT ... VALUES (...), (...), (...) из условных 5000 строк теперь не просто пишет в таблицу, а ещё и в binlog, синхронно, с фсинком.
На пике нагрузки это добавляет 20-30 мс к каждому батчу.
А когда таких батчей 100 в секунду - получаем как раз наш bottleneck.
Перед тем как вырубать, нужно убедиться, что никто не читает этот binlog.
Вдруг там не только дебезум был.
Сперва в консоли нечто типа:
Затем аудит самой MySQL:
Логи растут, но кто их читает?
Бегу проверять:
Никаких реплик.
Проверяю в AWS Console - DMS tasks нет.
Проверяю во всех Kubernetes - нет подов с Debezium, нет коннекторов.
Проверяем в IAM - нет ролей для DMS.
Проверяем в CloudWatch - нет метрик от коннекторов.
Теперь самое главное: спрашиваем бизнес. 😁
Собираем три команды: дата-инженеров, аналитиков, девопсов.
Вопрос простой: "Кто-нибудь реплицирует данные из Aurora куда-то ещё?"
Ответы:
- "Нет, мы теперь всё через Kinesis делаем"
- "Нет, мы используем S3 snapshots"
- "Нет, у нас только internal реплики на Aurora"
Сука.
Ок, Убедился, что binlog никому не нужен.
Теперь можно всё кильнуть.
Не уверен, что материал будет простым, но публикую как есть, как всё знал на момент этой стори.
Ко мне снова обратились с привычной проблемой: AWS, есть Aurora MySQL 3.*, большая нагрузка по кверям, увеличили инстанс, добавили CPU и памяти, даже меняли IOPS - но тормоза не ушли.
Особенно заметно на пиковых нагрузках, когда в систему летят десятки тысяч инсертов в секунду.
Знакомая история, которая всегда начинается с "мы уже всё перепробовали" и заканчивается у моего терминала.
Таска говно - впарить лоху (мне).
Не, ну ладно, зарплата сама себя не отработает, поехали разбираться.
Делаю привычное
SHOW PROCESSLIST - вижу волну wait/io/redo_log_flush.Коммиты висят по 50-100 мс, хотя дисковая подсистема вроде бы не жалуется.
Первое, что приходит в голову: а чо там, а чо, давайте смотреть на sync_binlog.
SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin | ON |
+---------------+-------+
SHOW VARIABLES LIKE 'sync_binlog';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
Сука.
Бинлог включен. Синхронный.
Каждый коммит ждёт фсинка на диск.
На Aurora MySQL 3.x, где кто-то раньше включил Enhanced Binlog (по дефолту он выключен, но у нас был исторически включён).
Вспоминаю, что на этом проекте был Дебезиум. Вроде бы.
Ладно, зацепка, иду в поиск.
Поднимаю историю по слаку, страницам RFC/PoC в Confluence.
Года три назад у нас был активный конвейер CDC на Debezium - реплицировали данные в Snowflake для аналитики.
Потом проект закрылся, команда разошлась, а инфраструктура осталась.
Кто-то выключил Debezium, кто-то отключил коннекторы, но binlog почему-то остался включённым.
"На всякий случай", "вдруг понадобится", "не трогай, оно работает".
Ну или девопс забыл
Только вот работает оно медленно. Каждый INSERT ... VALUES (...), (...), (...) из условных 5000 строк теперь не просто пишет в таблицу, а ещё и в binlog, синхронно, с фсинком.
На пике нагрузки это добавляет 20-30 мс к каждому батчу.
А когда таких батчей 100 в секунду - получаем как раз наш bottleneck.
Перед тем как вырубать, нужно убедиться, что никто не читает этот binlog.
Вдруг там не только дебезум был.
Сперва в консоли нечто типа:
aws dms describe-replication-tasks --region us-east-1 --query "ReplicationTasks[?Status!='stopped'].ReplicationTaskIdentifier"
aws iam list-roles --region us-east-1 --query "Roles[?contains(RoleName, 'DMS')].RoleName"
aws rds describe-db-parameters --db-parameter-group-name aurora-mysql3-params --query "Parameters[?ParameterName=='binlog_format'].ParameterValue"
Затем аудит самой MySQL:
SHOW BINARY LOGS;
+---------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000123 | 1073741824 | No |
| binlog.000124 | 1073741824 | No |
| binlog.000125 | 536870912 | No |
+---------------+-----------+-----------+
Логи растут, но кто их читает?
Бегу проверять:
SHOW REPLICAS;
Empty set (0.00 sec)
SELECT * FROM mysql.ro_replica_status;
Empty set (0.00 sec)
Никаких реплик.
Проверяю в AWS Console - DMS tasks нет.
Проверяю во всех Kubernetes - нет подов с Debezium, нет коннекторов.
Проверяем в IAM - нет ролей для DMS.
Проверяем в CloudWatch - нет метрик от коннекторов.
Теперь самое главное: спрашиваем бизнес. 😁
Собираем три команды: дата-инженеров, аналитиков, девопсов.
Вопрос простой: "Кто-нибудь реплицирует данные из Aurora куда-то ещё?"
Ответы:
- "Нет, мы теперь всё через Kinesis делаем"
- "Нет, мы используем S3 snapshots"
- "Нет, у нас только internal реплики на Aurora"
Сука.
Ок, Убедился, что binlog никому не нужен.
Теперь можно всё кильнуть.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥4🥰1
#aws #aurora #rds #troubleshooting
Делаем бэкап параметр группы (привычка), потом выключаем в правильном порядке:
Сначала проверяем, включён ли Enhanced Binlog:
Если 1 - значит, он был активен.
Тогда выключаем его правильно:
Выключить Enhanced Binlog:
Перезагружаем. Ждём перезагрузки.
Выключить сам binlog:
Ещё одна перезагрузка.
Важно (тут переуточнить в документации, если сами будете делать):
В Aurora MySQL 3.x binlog_backup = 0 используется только когда Enhanced Binlog включён. Если вы просто выставите binlog_backup = 0 без aurora_enhanced_binlog = 1 - это неправильная конфигурация. Правильный порядок: сначала гасим Enhanced Binlog через aurora_enhanced_binlog = 0, потом уже можно вырубать binlog_format = OFF.
Уже через 10-20 минут после перезапуска смотрим на графики.
А там у нас победа!!!!
Чо там чо там:
-
-
-
- Инсерты, которые раньше тормозили на 30-50ms, теперь выполняются за 8-15ms
Профиты повсюду:
- Команда разработки радуется.
- Мониторинг перестал краснеть.
- Яблоки вторым урожаем пошли.
- AWS Bill на IOPS снизился на $??? в месяц (не осталось в записях точная сумма).
Итоги:
- Всегда аудируйте binlog.
Даже если вы думаете, что он выключен - проверьте. SHOW VARIABLES LIKE 'log_bin' - ваш лучший друг.
В Aurora MySQL 3.x по дефолту Enhanced Binlog выключен, но могут остаться включёнными legacy-настройки.
- CDC - это не навсегда.
Когда выключаете Debezium, DMS или любой другой CDC инструмент - проверьте, что выключили всё.
Включая aurora_enhanced_binlog.
Особенно на Aurora, где Enhanced Binlog не нужен для internal репликации.
- синхронный binlog на write-heavy workload - убийца performance.
sync_binlog = 1 + инсерты = гарантированная latency.
Если вам не нужен binlog - выключайте через правильную последовательность: сначала aurora_enhanced_binlog = 0, потом binlog_format = OFF.
Если нужен - используйте Enhanced Binlog, он асинхронный и влияет на производительность меньше.
- документируйте зависимости
Если три года назад кто-то включил binlog для CDC - должна быть документация.
Если её нет - придётся расследовать, как детектив.
Используйте aws rds describe-db-parameters для аудита.
- не бойтесь выключать то, что не используете.
База не обидится. Зато станет быстрее.
Но делайте это в правильном порядке и в maintenance window.
- наймите уже DBA-шника, хватит мучать девопсов 😀
Делаем бэкап параметр группы (привычка), потом выключаем в правильном порядке:
Сначала проверяем, включён ли Enhanced Binlog:
SHOW VARIABLES LIKE 'aurora_enhanced_binlog';
Если 1 - значит, он был активен.
Тогда выключаем его правильно:
Выключить Enhanced Binlog:
aurora_enhanced_binlog = 0
binlog_backup = 1 (возвращаем обычный бэкап)
Перезагружаем. Ждём перезагрузки.
Выключить сам binlog:
binlog_format = OFF
Ещё одна перезагрузка.
Важно (тут переуточнить в документации, если сами будете делать):
В Aurora MySQL 3.x binlog_backup = 0 используется только когда Enhanced Binlog включён. Если вы просто выставите binlog_backup = 0 без aurora_enhanced_binlog = 1 - это неправильная конфигурация. Правильный порядок: сначала гасим Enhanced Binlog через aurora_enhanced_binlog = 0, потом уже можно вырубать binlog_format = OFF.
Уже через 10-20 минут после перезапуска смотрим на графики.
А там у нас победа!!!!
Чо там чо там:
-
CommitLatency снизился с 45ms до 12ms (99 перцентиль)-
WriteThroughput остался тем же, но WriteIOPS упал на 23%!!!!!!!! (только для этого проекта)-
wait/io/redo_log_flush в Performance Schema перестал быть топ-1 контрибьютором latency- Инсерты, которые раньше тормозили на 30-50ms, теперь выполняются за 8-15ms
Профиты повсюду:
- Команда разработки радуется.
- Мониторинг перестал краснеть.
- Яблоки вторым урожаем пошли.
- AWS Bill на IOPS снизился на $??? в месяц (не осталось в записях точная сумма).
Итоги:
- Всегда аудируйте binlog.
Даже если вы думаете, что он выключен - проверьте. SHOW VARIABLES LIKE 'log_bin' - ваш лучший друг.
В Aurora MySQL 3.x по дефолту Enhanced Binlog выключен, но могут остаться включёнными legacy-настройки.
- CDC - это не навсегда.
Когда выключаете Debezium, DMS или любой другой CDC инструмент - проверьте, что выключили всё.
Включая aurora_enhanced_binlog.
Особенно на Aurora, где Enhanced Binlog не нужен для internal репликации.
- синхронный binlog на write-heavy workload - убийца performance.
sync_binlog = 1 + инсерты = гарантированная latency.
Если вам не нужен binlog - выключайте через правильную последовательность: сначала aurora_enhanced_binlog = 0, потом binlog_format = OFF.
Если нужен - используйте Enhanced Binlog, он асинхронный и влияет на производительность меньше.
- документируйте зависимости
Если три года назад кто-то включил binlog для CDC - должна быть документация.
Если её нет - придётся расследовать, как детектив.
Используйте aws rds describe-db-parameters для аудита.
- не бойтесь выключать то, что не используете.
База не обидится. Зато станет быстрее.
Но делайте это в правильном порядке и в maintenance window.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11🔥6😁2
Заметка ненависти.
Бесят три типа переменных:
1)
Примеры:
- https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-k8s-stack/values.yaml#L39
- https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-operator/values.yaml#L224
Так сказать лучи негодования команде VM @VictoriaMetrics_ru1.
2)
Пример:
- https://github.com/Terraform-VMWare-Modules/terraform-vsphere-vm/blob/master/examples/example-vmname.tf#L65
По имени ожидаешь строку с FQDN, а это флаг "создавать имя как FQDN"🐒
https://github.com/Terraform-VMWare-Modules/terraform-vsphere-vm/blob/master/variables.tf#L144-L148
3)
Примеры:
- https://github.com/krateoplatformops/eventrouter/blob/main/main.go#L60-L66
cfg без какого‑либо намёка, что это именно Kubernetes REST‑конфиг, а не, скажем, конфиг логгера или чего‑нибудь ещё.
Пока не откроешь импорты и десяток файлов вокруг ни черта не понять.
- https://github.com/vmware-tanzu/vm-operator/blob/main/main.go
cfg тут - это kubernetes REST конфиг, через который оператор лезет ко всему API кластера, но по имени это просто "какой‑то конфиг" без намёка, что именно kubeconfig, а не, например, конфиг логгера или самого приложения. Чтобы это понять, нужно либо знать паттерн ctrl.GetConfigOrDie, либо докручивать в голове по managerOpts.KubeConfig = cfg и типам. Бред.
Голанг комьюнити допускает короткие имена вроде cfg для переменных узкой области видимости, но здесь это используется на уровне файла! Алё! Тут сокращение несёт неочевидный смысл.
Бесит короч иногда.
Бесят три типа переменных:
1)
double negative (Двойное/обратное отрицание).Примеры:
- https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-k8s-stack/values.yaml#L39
operator:
disable_prometheus_converter: false
- https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-operator/values.yaml#L224
operator:
enable_converter_ownership: true
Так сказать лучи негодования команде VM @VictoriaMetrics_ru1.
2)
unintuitive / non-descriptive names (Неочевидные имена)Пример:
- https://github.com/Terraform-VMWare-Modules/terraform-vsphere-vm/blob/master/examples/example-vmname.tf#L65
module "example-server-fqdnvmname" {
...
fqdnvmname = trueПо имени ожидаешь строку с FQDN, а это флаг "создавать имя как FQDN"
https://github.com/Terraform-VMWare-Modules/terraform-vsphere-vm/blob/master/variables.tf#L144-L148
variable "fqdnvmname" {
description = "If true, the vm will be created using domain variable appended"
type = bool
default = false
}3)
cryptic names (Криптические имена)Примеры:
- https://github.com/krateoplatformops/eventrouter/blob/main/main.go#L60-L66
var cfg *rest.Config
var err error
if len(*kubeconfig) > 0 {
cfg, err = clientcmd.BuildConfigFromFlags("", *kubeconfig)
} else {
cfg, err = rest.InClusterConfig()
}
cfg без какого‑либо намёка, что это именно Kubernetes REST‑конфиг, а не, скажем, конфиг логгера или чего‑нибудь ещё.
Пока не откроешь импорты и десяток файлов вокруг ни черта не понять.
- https://github.com/vmware-tanzu/vm-operator/blob/main/main.go
func initRateLimiting() {
if rateLimiterQPS == 0 && rateLimiterBurst == 0 {
return
}
cfg := ctrl.GetConfigOrDie()
...
managerOpts.KubeConfig = cfg
}cfg тут - это kubernetes REST конфиг, через который оператор лезет ко всему API кластера, но по имени это просто "какой‑то конфиг" без намёка, что именно kubeconfig, а не, например, конфиг логгера или самого приложения. Чтобы это понять, нужно либо знать паттерн ctrl.GetConfigOrDie, либо докручивать в голове по managerOpts.KubeConfig = cfg и типам. Бред.
Голанг комьюнити допускает короткие имена вроде cfg для переменных узкой области видимости, но здесь это используется на уровне файла! Алё! Тут сокращение несёт неочевидный смысл.
Бесит короч иногда.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🥰1🙏1👌1
Адвент-календарь декабря 2025 ❤️
После шикарных подарков от CloudFlare и GitHub, красочно подхватывает эстафету и выдаёт DockerHub.
https://www.dockerstatus.com/
После шикарных подарков от CloudFlare и GitHub, красочно подхватывает эстафету и выдаёт DockerHub.
https://www.dockerstatus.com/
3🔥13
#пятница #всратость
На работе защита везде и всюду:
- рабочий ноутбук без прав администратора, с целым зоопарком антивирусов и систем контроля доступа.
Сам Евгений по утрам приезжает и лично проверяет твою авторизацию.
- вход в кубер через SSO, OIDC, VPN со временем сессии 2 часа, ролевая модель строже и острее, чем шутки в 1937 году, девелоперы могут быть только в UI ArgoCD с read-only, а каждый чих логирует SIEM, и если ты случайно нажал F5 чаще, чем раз в 5 секунд, срабатывает правило "Potential Brute Force" и тебя блочат.
- никакого интернета, только внутренние ресурсы. Везде distroless или SBOM, имаджи сканирует Trivy, депенданси бот обновляет версии. Вайтлист на реджистри, OPA. Три контура container registry, с ручной перекладкой имаджей и immutable тегами. Три контура CICD с разделением доступов по командам и подпись образа через Cosign.
- внутри нетворк полиси, ингрессы с сертами, самообновляющиеся каждые 7 дней, свой собственный удостоверяющий центр, мтлс и даже егрессы, чтобы чётко знать куда и чего. Инженерный комитет еженедельно составляет список обязательных сертификатов и ключей, которые обязаны быть в контейнерах.
- инфобеза угорает по файрволам между immutable Talos нодами и натягивает Istio везде, даже на глобусы. В системе логируется буквально всё: ивенты, ивенты ивентов, даже команды от дебаг контейнеров типа ls. Собственно и kubectl debug не работает, когда ты пытаешься запустить busybox, ведь OPA его блокирует, потому что не в вайтлисте. Все логи не просто собираются, а дублируются в три разных S3-бакета, каждый из которых зашифрован своим KMS-ключом, который ротируется каждые 2 часа
- всё обвешано киверно политиками, от замены пути к имаджам, до принудительного обмазывания капабилитис. Уже оператор Trivy сканирует в рантайме имаджи, пофиг, что в CI/CD уже сканировалось.
- повсеместно селинукс, секьюрити контекст, рутлес, капабилитис.
Всем запрещено монтирование секрета куба, доступ к нему только по заявке и аппрувом Его Самого.
- все коммиты в git проходят через 4 уровня ревью: обычный code review, security review, compliance review и финальный ревью от инфобеза, где они проверяют, не закодировал ли ты в YAML отступах какие-нибудь вредоносные секреты.
Каждый мердж в мастер требует подписи руководителя департамента
- пароль от БД не знает даже дба - оператор сам создает пароль и хранит в волте, доступ только у оператора, пароль инжектится напрямую в апп, даже в секретах не узнать. Все проходят PCI DSS v4, SOC2 и даже DRP в случае нападения казаков.
- всюду SAST, DAST, DU HAST, CIS, SCA, хоть и не все понимают что это и зачем, но покорно используют
- админы опеншифта и кубера общаются между собой исключительно через вебхуки и admission-контроллеры
- каждый месяц проходишь тесты на полиграфе, доказывая, что никаких закладок не делал, ты всего-лишь пилил пайплайны. Вокруг датацентра ров с акулами, колючей проволокой в башкирском мёде, вертолёты и собственная армия с малой авиацией. При выдаче USB-токена при старте работы проходишь квест убегания от служебных собак, тренировка на скорость и выносливость, ведь слабаки нам не нужны.
.
..
...
А в это время в Перми, весело щебеча, словно воробушек, операционистка Валентина делает "клац-клац" фотокамерой с телефона, сливая все данные клиентов на экране монитора её панели оператора, за сумасшедшие 3500 рублей, которые ей пообещали анонимы в телеграме, наплевав на DLP, ведь она об этом даже и не знала.
.
..
...
Инфобеза тратит ещё миллиард денег, чтобы провести расследование и внезапно доказывает, что виноваты девопсы, опять всё сделали не так. Ведь так оно и есть. Во всём везде и всегда виноваты девопсы.
На работе защита везде и всюду:
- рабочий ноутбук без прав администратора, с целым зоопарком антивирусов и систем контроля доступа.
Сам Евгений по утрам приезжает и лично проверяет твою авторизацию.
- вход в кубер через SSO, OIDC, VPN со временем сессии 2 часа, ролевая модель строже и острее, чем шутки в 1937 году, девелоперы могут быть только в UI ArgoCD с read-only, а каждый чих логирует SIEM, и если ты случайно нажал F5 чаще, чем раз в 5 секунд, срабатывает правило "Potential Brute Force" и тебя блочат.
- никакого интернета, только внутренние ресурсы. Везде distroless или SBOM, имаджи сканирует Trivy, депенданси бот обновляет версии. Вайтлист на реджистри, OPA. Три контура container registry, с ручной перекладкой имаджей и immutable тегами. Три контура CICD с разделением доступов по командам и подпись образа через Cosign.
- внутри нетворк полиси, ингрессы с сертами, самообновляющиеся каждые 7 дней, свой собственный удостоверяющий центр, мтлс и даже егрессы, чтобы чётко знать куда и чего. Инженерный комитет еженедельно составляет список обязательных сертификатов и ключей, которые обязаны быть в контейнерах.
- инфобеза угорает по файрволам между immutable Talos нодами и натягивает Istio везде, даже на глобусы. В системе логируется буквально всё: ивенты, ивенты ивентов, даже команды от дебаг контейнеров типа ls. Собственно и kubectl debug не работает, когда ты пытаешься запустить busybox, ведь OPA его блокирует, потому что не в вайтлисте. Все логи не просто собираются, а дублируются в три разных S3-бакета, каждый из которых зашифрован своим KMS-ключом, который ротируется каждые 2 часа
- всё обвешано киверно политиками, от замены пути к имаджам, до принудительного обмазывания капабилитис. Уже оператор Trivy сканирует в рантайме имаджи, пофиг, что в CI/CD уже сканировалось.
- повсеместно селинукс, секьюрити контекст, рутлес, капабилитис.
Всем запрещено монтирование секрета куба, доступ к нему только по заявке и аппрувом Его Самого.
- все коммиты в git проходят через 4 уровня ревью: обычный code review, security review, compliance review и финальный ревью от инфобеза, где они проверяют, не закодировал ли ты в YAML отступах какие-нибудь вредоносные секреты.
Каждый мердж в мастер требует подписи руководителя департамента
- пароль от БД не знает даже дба - оператор сам создает пароль и хранит в волте, доступ только у оператора, пароль инжектится напрямую в апп, даже в секретах не узнать. Все проходят PCI DSS v4, SOC2 и даже DRP в случае нападения казаков.
- всюду SAST, DAST, DU HAST, CIS, SCA, хоть и не все понимают что это и зачем, но покорно используют
- админы опеншифта и кубера общаются между собой исключительно через вебхуки и admission-контроллеры
- каждый месяц проходишь тесты на полиграфе, доказывая, что никаких закладок не делал, ты всего-лишь пилил пайплайны. Вокруг датацентра ров с акулами, колючей проволокой в башкирском мёде, вертолёты и собственная армия с малой авиацией. При выдаче USB-токена при старте работы проходишь квест убегания от служебных собак, тренировка на скорость и выносливость, ведь слабаки нам не нужны.
.
..
...
А в это время в Перми, весело щебеча, словно воробушек, операционистка Валентина делает "клац-клац" фотокамерой с телефона, сливая все данные клиентов на экране монитора её панели оператора, за сумасшедшие 3500 рублей, которые ей пообещали анонимы в телеграме, наплевав на DLP, ведь она об этом даже и не знала.
.
..
...
Инфобеза тратит ещё миллиард денег, чтобы провести расследование и внезапно доказывает, что виноваты девопсы, опять всё сделали не так. Ведь так оно и есть. Во всём везде и всегда виноваты девопсы.
15🤣25🔥6😁6💯4❤1