Им нужен Kubernetes. Это не мнение - я проверил.

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

Кластер есть - kubernetes нет. Использовали как сервер-помойку с кучей сайтов.

- Нагрузка без requests/limits.
- Namespace projectname-dev соседствует с website-www - то есть с продом.
- Три ноды, без автоскейлинга и мониторинга.
- StorageClass только RWO - общий диск без affinity не работает, с affinity теряется смысл.
- Деплой сырых манифестов через kubectl apply, образы с тегом latest.

И вот я пришёл. Создал Helm chart для нового сервиса с requests/limits - как положено.
Новый под завис Pending.

Кластер overprovisioned.

Вопрос не "нужен ли вам Kubernetes".

Вопрос - готовы ли вы к нему.

"БД в рид-онли, ничего не работает."

Без уточнения. Какой проект, какое приложение - не написали.
У клиента их четыре и десять.

Нашёл нужный.

Диск - 100%. Реплика - read-only:on. Смотрю размеры таблиц:

exception_logs  |  33 ГБ
failed_jobs     |  15 ГБ
jobs            |  22 ГБ

Нахрена писать логи в ту же базу что и данные?

Ладно. Смотрю что в этих логах:

cURL error 6: Could not resolve host: teams-webhook-url

В helm values кто-то добавил:

TEAMS_WEBHOOK_URL: "teams-webhook-url"

Буквально строку "teams-webhook-url". Идея - пусть берёт значение из переменной Bitbucket Pipelines. Вот только в пайплайне забыли его установить через --set.

И понеслось:

exception → пишет лог в БД → пытается отправить в Teams → хост не резолвится → exception → пишет лог → пытается отправить → ...

Пока не забило диск.

Попробовал почистить таблицы - не вышло.
База managed в OVH: пользователей создаёшь через веб-интерфейс, суперпользователя назначить нельзя - OVH не даёт.
А без суперпользователя писать в read-only базу невозможно.

Остался один вариант. Сбросил базу. Восстановил из бэкапа.

Итог: система оповещений об ошибках положила базу данных.

Бэкап был. Повезло.

Если вы узнали что прод упал - от клиента -
у вас не прод. У вас MVP.

Вы запустили продукт. Клиенты им пользуются. Уже хорошо.
Но продакшен без мониторинга - это ваш клиент в роли дежурной смены.

На интервью DevOps-инженера спрашивают: "как вы действуете при звонке 'прод упал'?"
Хороший ответ: "такого звонка не должно быть".

Не потому что DevOps такой крутой.
А потому что система должна знать о проблеме раньше клиента. Всегда.

Как выглядит нормально:

СТО утром получает сообщение:
"Ночью упало X. Даунтайм 5 минут. Причина такая. Пофиксили так. Постмортем к вечеру."

Не звонок от клиента. Отчёт от команды.

Если у вас иначе - вопрос не к DevOps.
Вопрос к вам: как так получилось, что клиент узнал раньше?

"Прод упал" - это не задача. Это начало разговора.
DevOps знает какой прод упал - или ждёт пока объяснят?

Листал ленту LinkedIn. Увидел пост про "многие девопсы не знают" - и там вопрос: "прод упал, что сделаешь первым делом?"

Ответил в комментарии: "спрошу какой именно прод".

Меня поддержало мало людей. Большинство рассказало как они в AWS будут что-то проверять.

Ребят, а с чего вы взяли что это в AWS?

У одного моего клиента инфраструктура: AWS, GCP, Alibaba и AWS-CN.
Чем мне помогут логи AWS?

По-хорошему - алерт от мониторинга уже ответил бы на этот вопрос. Но раз звонок случился:

Итак, прод упал.
Что я сделаю первым?
Я спрошу: что конкретно упало, что видит клиент, как давно?

Потом - документация, ранбуки. Потом логи и метрики.

Не после того как посмотрю логи. До.

Кто не спрашивает - тот тушит соседний дом вслепую.

S3 выглядит дёшево. Пока не посмотришь в счёт.

Коллега рассказал: предложили им сделать бэкап данных в Yandex Cloud. 600ТБ.
Посчитали egress из S3.
Разговор закончился.

---

У меня была похожая история, но поменьше.

~60ТБ в S3, три аккаунта, около 50 бакетов. Приложение крутится в GKE.
Данные идут из S3 в приложение - платим S3 egress на каждом запросе.
Попросили посмотреть: может дешевле держать в GCP Buckets, раз уж инфра там?

Посчитал только хранение: S3 $1,422/мес, GCS $1,237/мес. Разница $185.
Egress при переезде $5,530 разово. Окупаемость ~30 месяцев.

Посчитал трафик: $101/мес egress S3→GKE - внутри GCP бесплатно.

Итого: экономия $286/мес. Окупаемость ~19 месяцев.

---

Но вот что интересно.

Трафик показывает: из 60ТБ за год выкачивается дай бог треть.
Остальное - мёртвый груз.

Что реально делать:

Включить Storage Lens - хотя бы бесплатный. Понять что вообще есть в этих бакетах, что читается, что лежит мёртвым грузом.
Потом сесть и проверить содержимое: старые ушедшие клиенты, старые версии, просто мусор. Да, долго и муторно. Но скорее всего половину можно просто удалить.

Переписать приложение: при получении файла из S3 - сохранять копию в GCS. Самые используемые файлы переедут сами, постепенно, без разового egress на $5,500.
Да, это время разработчика - которого всегда не хватает и которое можно потратить на фичи или закрытие уязвимостей.

---

Никто этого не делает. Потому что больно, долго, не горит.

А Amazon тебя не торопит.
Просто регулярно выставляет счёт.

Как сломать свой HA мониторинг одним дашбордом?

Все мы знаем что HA делается для "высокой доступности" - распределения нагрузки на несколько инстансов плюс на случай если один упадёт, второй-третий продолжат работать без него.

И это правильно. Но всегда есть нюансы. Например, сломать или перегрузить внутреннюю логику самого приложения - когда выполняя заложенную функцию оно дохнет. На это направлены атаки DoS: заставить приложение выполнять тяжёлую работу простым запросом.

---

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

Но как результат этих запросов мы получали быстрорастущий список уникальных метрик - каждая метрика имела label endpoint с уникальным путём, который ботнет перебирал сотнями. Не нескольких метрик с разными значениями, а тысячи уникальных метрик с несколькими значениями каждая.

Для Prometheus это очень дорого - на каждую метрику создаётся своя серия данных. И если в одной серии данные хранятся компактно, то много коротких серий занимают гораздо больше места.

Thanos storage пух. Незаметно.

---

При чём здесь дашборд?

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

И этот дашборд для графиков дёргал метрики. Все метрики приложения. Все серии данных. Они короткие, но их очень много.

И тут не помогал никакой HA - при выполнении запроса promql thanos-query выжирал память как не в себя и убивался по resource limit. Каждая реплика, по очереди.

(А до этого убивал ноды, специально выделенные под мониторинг - изначально лимиты не были прописаны. Вот такой HA.)

---

Попытка сделать высокую доступность мониторинга успешно херилась кривыми метриками приложения.

Дашборд который должен был показывать что всё работает - ронял мониторинг при открытии.

Prometheus бесплатный. Пока не посчитаешь.

Смотришь на кластер - и начинаешь считать: а это что за поды?

prometheus-0           3387 MB
prometheus-1           3028 MB
thanos-store-0          439 MB
thanos-store-1          899 MB
thanos-query            486 MB
thanos-query            139 MB
thanos-compact          300 MB
thanos-bucket            13 MB
grafana                 334 MB
kube-state-metrics       40 MB
prometheus-operator      21 MB
prometheus-adapter       24 MB
blackbox-exporter        16 MB
node-exporter ×8         ~10 MB каждый

Это только мониторинг. ~9.5 GB RAM, 20+ подов.

---

kube-prometheus-stack разворачивает всё это одной командой. Дефолты почти разумные - надо только включить хранилище и выставить лимиты под свой кластер. По умолчанию ни того ни другого нет.

На трёхнодовом кластере стек мониторинга легко занимает 20-30% ресурсов кластера. Это до того как начал мониторить само приложение. На больших проектах мы обычно выделяем отдельный nodepool под мониторинг - минимум две ноды. Чтобы мониторинг не аффектил рабочую нагрузку. И чтобы рабочая нагрузка не влияла на мониторинг.

Это уже не просто ещё несколько подов. Это отдельные машины которые работают круглосуточно.

---

Главный пожиратель - Prometheus. И RAM и диск зависят от трёх вещей: сколько метрик, как часто скрейпишь, сколько хранишь.

Грубая математика: 100 000 метрик × 30 дней retention × скрейп каждые 15 секунд ≈ 25-40 GB. Это небольшой кластер. Нагруженный - 500K метрик → 200-300 GB. И это только Prometheus.

---

Стоимость обслуживания считают реже чем стоимость ресурсов.

Обновление стека - раз в квартал разумно, breaking changes бывают (да и при minor версии тоже, хоть и не должен). Ревизия алертов - старые rules устаревают вместе с приложениями, алерт на сервис которого уже нет это просто шум. Grafana дашборды - кто-то должен их поддерживать. Обычно никто. Потом "а почему тут данные не показываются" - а сервис переименовали три месяца назад.

Реалистично: 2-4 часа в месяц если всё здорово. Плюс время на инциденты.

---

Prometheus бесплатный.
За Datadog ты не платишь - ты же его не покупал.

Берут временем людей, ресурсами кластера и вниманием которое надо поддерживать чтобы это работало.

Ты знаешь сколько это стоит тебе?

Это мистер Коди. Он приходит к тем кто лжет и заставляет их исправиться.

Слышит по радио: "все говорят о том-то". Лезет за ручкой. "Мы с тобой говорим об этом? Нет. Значит лгут. Надо навестить."

Трасса 60. Было смешно. Запомнилось.

Листаю линкедин.
"Все используют kubernetes..."
"Все уже используют AI..."
"Все/Никто блабла..."

"Все" - это такой эвфемизм "я не знаю, но хочу набросить на вентилятор и словить хайп".
Кто эти все? Они с вами сейчас в одной комнате?

В коде переменная без значения не компилируется. В тексте - пожалуйста, написал, опубликовал и ждешь лайки.

Рука тянется к кнопке "перестать отслеживать". Не потому что я хочу что-то продемонстрировать, и пусть он жалеет что я его не читаю.
Нет.
Просто я понимаю что ничего полезного для меня он не скажет.

«Ну и заодно дай доступ к CloudSQL.»
Нашёл базу на $342 в месяц. В dev.

Разработчик попросил настроить CI/CD в GKE. Ну и «заодно». Добрался до CloudSQL - он уже создал инстанс вручную. К счастью, доступ у него только к dev.
250 ГБ - в 25 раз больше нужного. Enterprise Plus - инстанс $342/мес вместо $32 для dev. Публичный IP. В регионе, отличном от кластера - межрегиональный трафик платный, и задержки на каждый запрос.

Дал по рукам. Сделал нормально. (Это включая объяснение как пользоваться bastion host для доступа к CloudSQL без публичной сети.)

---
В течение следующих двух месяцев периодически: "а надо ещё вот это задеплоить". Новый пайп, отдельные права в GCP, допресурсы. Постоянно возникали дополнительные требования.

LB для HTTP2/gRPC, но без TLS на поде. Потом внезапно один сервис оказался WebSocket - "а чего он не работает?" Таймаут. Надо нужный ставить, а не дефолтные 30 секунд.

Потом один из сервисов убрали из GKE - "мы перенесли его в Cloud Function". Ну ок. Как будет готово - допилим IaC.

---
Вечером в пятницу разработчик объявил: "Я думаю, мы готовы деплоить в прод. Не прям срочно, но хотелось бы как можно скорее."

И привёл список из 8 пунктов.

Я настраивал 7. Один удалили. Должно быть 6. Это сильно.

Выясняется.

Тот "удалённый" сервис - это "CloudRun Function". Так Cloud Run или Function? Как деплоили? Тот же репо или отдельный?

8-й пункт - PubSub топик. Тоже создан руками.

---
Звучит как жалоба на дебилов? Ну есть маленько.

Но есть важный нюанс. Без DevOps этот же разработчик смог бы запустить всё это в прод - и оно бы работало. Некоторое время. Вполне реально.

Вот только вопрос цены. Размер инстансов? Больше чем нужно, или ещё хуже - меньше чем нужно. База в другом регионе - трафик между регионами платный, задержки на каждый запрос. Кривые права - один SA с максимальными правами на всё. Отсутствующая автоматизация и резервирование. Публичный доступ ко всему.

Молодцы, сделали так чтобы работало. Теперь давайте проверим и сделаем так чтобы работало надёжно и за разумные деньги.

Что вы почувствуете, когда ваш сайт с историей за 5 лет будет полностью удален одним неловким движением?
Я не могу вас сказать, я не был на той стороне.
Но я могу поделиться что я почувствовал когда сделал это.

Я удалил сайт с хранилищем и базой на 110 гигабайт. Это не особо много, но это вся история бизнеса за 5 лет.
Вы можете сказать - "плохо что даунтайм, наверное целый день/ночь восстанавливал?"
Нет.
Я удалил его полностью, без возможности восстановления.
Потому что там не было никаких бэкапов. Никаких. Ни настроек, ни контента. Ничего.
Сайт буквально жил на носу несущейся ракеты, и я просто был тем самым камешком что сбил его просто коснувшись.

Там не было никаких бэкапов, ни регулярных автоматических, ни ручных, и даже я перед нажатием кнопки delete не сделал бэкап.
Причина? Я удалял не прод, я удалял дев. Но из-за похожих имен я удалил очень нужный, работающий сайт.
Да, это было единое окружение для дев и прод.

Итак, что вы чувствуете? Представьте эту ситуацию:
Ваш успешный сайт/сервис/приложение работало-работало, а потом бац! и ваш сотрудник случайно его удаляет.
Давайте, не стесняйтесь, прочувствуйте это.
5 лет SEO. Позиции в Google которые копились годами - это не восстанавливается за день, это месяцы работы поисковика.
Контент написанный вручную. Аккаунты пользователей. История заказов, обращений, всего что там было.
Все что нажито непосильным трудом, длинными ежедневными часами разработки, написания, редактирования, все пропало.
Совсем пропало. Абсолютно. Исчезло.


ЗЫ:

Здесь должна быть история как мы успешно все восстановили, LessonLearned и прочий буллшит.
Но ее не будет.
Потому что здесь нечего восстанавливать. Да, картинки наверное остались. Может быть осталось что-то еще. Где-то.
Но это не восстановление из бэкапа, даже супердолгое.
Это пересоздание, кем-то как-то... Это может стоить вам бизнеса.

матрица эйзенхауэра, рис, wtf и другие матерные слова в работе инженера

"Как вы расставляете приоритеты между задачами - например, вот фронтендеры хотят срочно сейчас, и бэкендеры тоже хотят срочно сейчас, но другое?"
Я вот задумался...
Как-то не возникало раньше настолько конфликтующих задач, когда час времени влияет. Обычно хватало "сегодня сделаю", и так получалось что что-то я делал в первую очередь (попроще, понятнее, просто быстрее), а что-то во вторую, но в рамках одного дня это не существенно. Если же задача больше чем на один день - то тем более не критично.

-—
В командах с тимлидом это его головная боль. Но работая соло с несколькими командами одновременно - приходилось развивать и навыки планирования.
В-основном это выглядит как интуиция - "это быстро, сделаю", "тут надо копаться, но команде не горит, отложу и спокойно изучу", "это срочно, бросаю все и жечь напалмом".
На самом деле - тут все логично, и даже есть умные слова для определения методик.
Я их не знал, мне хватало нормального описания в книге "Тайм-менеджмент для системного администратора" Томаса Лимончелли, чем, собственно, и руководствовался все 16+ лет.

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

Матрица Эйзенхауэра - это тот крестик с половинами "срочно/не срочно" и "сложно/не сложно", или как-то так. Это первичный фильтр. Прод горит? Чини сейчас. Остальное - сортировка.
RICE - для планирования. (Reach × Impact × Confidence) / Effort. Дает число. Ну а потом сортируешь по величине, да и все.
WSJF - для выбора "что делать прямо сейчас". Учитывает стоимость задержки - что мы теряем каждый день пока не решили. CI/CD падает каждый третий деплой? Каждый день теряются часы инженеров. QA ждет окружение? Пока не ждет - у него есть другие задачи. Отрубился автомат в распредщитке в офисе - оооо, почти все сотрудники бездельничают, а часы капают.

-—
Вот я узнал, даже записал. В другой раз всплыл аналогичный вопрос - единственные термины что вспомнил - "матрица эйзенхауэра" и "планнинг покер".
Ну что поделать, в работе их называть мне обычно не надо)))) Хватало делать все вовремя в нужном порядке.

Если же вам надо регулярно приводить аргументы почему надо делать что-то в первую очередь - то держите конспект, и сделайте из него шпаргалку при подготовке к разговору. medium

Вы дали ИИ больше прав чем новичку в его первый день?
И чему вы удивляетесь?

Я использую ИИ (claude code), реально полезная штука. Планирую, обсуждаю архитектуру, прошу написать код, проверяю.
И никогда не позволяю "сделай что-нибудь, вот тебе права на всё".

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

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

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

В результате, кубер кластер я создал за два часа, примерно. Делаешь по плану, что-то не так - фиксишь, продолжаешь.
Во второй прогон я поднял его за 40 минут.


Когда я читаю всякие новости "блабла сломалось из-за того что ai получил слишком широкие права; аи обошел запрет и получил права и удалил кластер;"...
Мне дико странно такое видеть.

Vercel взломали в апреле 2026 из-за нажатия "Разрешить все".

Я воспринимаю ИИ-помощников как джунов. Он пишет код, не всегда оптимальный, но очень быстро. Я планирую, правлю архитектуру, с его помощью и вместе мы получаем результат быстрее.
Но пустить его в прод, сказать "эй, сиди здесь, обрабатывай запросы, вот тебе рут-доступ" - вы ебанулись?

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

Вот прямо сейчас возьмите и проверьте как ваши сотрудники могут сломать вашу систему.

K8s 1.26->1.33. 4 часа нажатия кнопки "обновить" в Oracle Cloud.

Там нодпул жесткий, оказывается, а не динамический.То есть, при создании нодпула вручную указываешь AZ где создавать, отдельно для каждой ноды!!!!! и так же руками указываешь сеть.
Вот где я с благодарнростью вспомнил ноды gke, которые автоматически динамически обновляются сами, незаметно.

И вот я руками в веб-консоли нажимаю кнопку "обновить", три раза, с паузами.
Создаю новый нод пул со второй попытки, отключаю старые ноды по одной (даунтайм подов до 14 минут! что у них там с сетью?).
Снова жму "обновить" три раза... Создаю новый нодпул, отключаю старые ноды...
Жму "обновить" два раза и решаю на этом остановиться - ибо уже дофига на это потратил, и слава яйцам версия 1.34 будет актуальна до октября 2026.

Всё началось с диска D.

Помните? Игры на D, документы на D. Диск C - под систему, раз в полгода форматируем.
Один мой коллега пошёл дальше: настроил винду один раз, снял образ, и после форматирования накатывал именно его. Не переустанавливал - восстанавливал.

Прошло двадцать лет. Мы называем это "контейнерами".
Та же идея: данные отдельно, исполняемые файлы отдельно. Только теперь сама ОС стала "исполняемыми файлами". Запустил новый образ - всё работает.

И вот вопрос: зачем тогда делать do-release-upgrade на нодах кубер кластера?

Вывел ноду из ротации. Накатил новый образ. Вернул в кластер.
Это не обновление - это замена. Намного чище.

Не процесс - результат.

Я не смог объяснить что я делаю.
Я пытался простыми словами объяснить чем я занимаюсь как айтишник.

Вот эти все облака, девопс культура, сервера...

Человек взрослый, современный, пользуется телефоном, компьютером, сайтами и приложениями.
Никак.

Это было обескураживающе.

Помогите - как объяснить "пятилетнему" что такое "сервер", и что такое "облако"?
Просто, без зауми и лекций на месяц для определения терминологии.

Помните историю как я грохнул продакшен сайт без возможности восстановления? https://www.linkedin.com/posts/anton-yushkov_devops-backup-incident-activity-7458476375423963136-ri1W

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

Всего-то небольшой конфиг, скрипт для копирования бд и файлов на сетевое хранилище, и настройки для регулярного запуска в кластере.
Меньше одного рабочего дня на создание, еще день на отладку и проверку.

Один день обычной работы против недель на восстановление и неизвестное количество усилий.

У вас есть бэкапы? Точно?

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

Это как с вакансиями - сначала пара больших абзацев про крутую команду и как мы меняем мир, потом key requirements.
Я читаю только requirements.

Короче, клиент: стартап, что-то для школ в США.
У них был рабочий проект, клиенты, нормально всё.
Правильный стартап - сделали чтобы работало, получили клиентов, на заработанное допиливают чтобы работало надёжно.

Что я знаю про проект? Полностью серверлесс - лямбды, S3, Aurora. Cognito, apigw - ну там тоже всё это есть.
Смотришь архитектуру, уточняешь детали, оптимизируешь, пишешь terraform/terragrunt, новый аккаунт, CI/CD, мониторинг. Стандартно.
Сделали, остались на поддержке - под новые фичи допилить, и всё такое.

Чем они занимаются? Честно - не знаю. Я как-то пропустил представление, или не вслушивался, или просто забыл.
Нам абсолютно насрать в чём заключается их уникальная идея. Нас спрашивали про лямбды.

Справились два девопса на полдня за пару месяцев.

Звёздная история? Её нет.
Просто обычная работа.

Есть клиенты у которых деньги есть. Есть клиенты у которых денег нет. И есть третий тип.

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

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

Владельцы же бизнеса "так себе", вроде и не загибается но и успешным успехом не назвать. Наверное, самый некомфортный тип клиентов.
Хотят вот этого всего забесплатно.
Я писал пост о них. Почти год думали, вроде решились.
Неделю им делал, красиво расписал, все подсвечено...
"если со своей стороны подтвердите что вот этот кластер не нужен (а я проверил - на него трафика нет, доменов нет, данных нет), то разом срежем половину ваших затрат. Ну и остальное вот тут, тут и тут - почти половину от оставшейся половины"
"На данный момент этот твой аудит для нас - чистый расход, никакой пользы. Это должно было быть сделано в рамках имеющегося контракта devops support."

Ну блин.

Ты потерял $35,000. Хочешь знать где?

Для тех кто регулярно платит за AWS и не уверен что понимает за что именно.

Ни один клиент не ушёл без находки. На скрине $1000/m только за extended support старых версий БД. И это не самый крупный случай.

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

- Без погружения в биллинг, тарифы и учёт трафика
- Без страха выключить нужное и уронить прод
- Ты рассказываешь - я показываю что и где. Чётко, без жаргона

Посмотри как это выглядит → https://itaudit.yushkov.org/reports/demo/