Ну что сказать... кажется можно подвести итоги этого года...
Декабрь выдался... каким-то безумным на события, та и в целом как и весь год.
Мы провели M*CTF и знаете... провели его... во многом выше всех своих ожиданий, это было здорово, надеюсь это не был наш пик, в следующем году... сделаем еще круче😁
Спасибо большое всем ребятам, что участвовали в разработке и помогали нам организационно, думаю мы правда в этом году молодцы.
А касательно... каких-то личных итогов, многое было...
- Приглашение в IBM / RHEL
- Личное знакомство с ДеХаном и ряда очень и очень крутых экспертов
- Мой любимый PTLab и надеюсь новая фаза его развития
- Автоматизация источников
- Закончился проект который было очень сложно отпускать
- Началось что-то действительно очень крутое и новое
Короче... давайте уже по традиции этого канала:
- Спасибо всем, кто читает и интересуется всем, что тут происходит, я думаю у нас с вами много крутого впереди💖
- Я думаю все будет круто😻
- С наступающим вас, будьте умничками :3🕺
Декабрь выдался... каким-то безумным на события, та и в целом как и весь год.
Мы провели M*CTF и знаете... провели его... во многом выше всех своих ожиданий, это было здорово, надеюсь это не был наш пик, в следующем году... сделаем еще круче
Спасибо большое всем ребятам, что участвовали в разработке и помогали нам организационно, думаю мы правда в этом году молодцы.
А касательно... каких-то личных итогов, многое было...
- Приглашение в IBM / RHEL
- Личное знакомство с ДеХаном и ряда очень и очень крутых экспертов
- Мой любимый PTLab и надеюсь новая фаза его развития
- Автоматизация источников
- Закончился проект который было очень сложно отпускать
- Началось что-то действительно очень крутое и новое
Короче... давайте уже по традиции этого канала:
"местами даже хорошо... что он подходит к концу."
- Спасибо всем, кто читает и интересуется всем, что тут происходит, я думаю у нас с вами много крутого впереди
- Я думаю все будет круто
- С наступающим вас, будьте умничками :3
Please open Telegram to view this post
VIEW IN TELEGRAM
🎄36❤19❤🔥12
This media is not supported in your browser
VIEW IN TELEGRAM
Чтож... потихоньку начинаем публиковать труд, который пережил кучу итераций и мнение множества экспертов...
Сейчас хоть не стыдно показать😮
➡️ PT_LEP_Unix
Роль для настройки на источниках формата событий, правил журналирования, служб журналирования (rsyslog или syslog-ng) и отправки событий syslog через audispd.
➡️ PT_dc_policy
Роль предназначена для добавления следующих политик на контроллерах домена (DC):
- PT_Event_LogReader - политика для сбора событий с целевых хостов, добавления группы MaxPatrol Group LogReader (в ней содержится пользователь под которым идет сбор логов) в локальную группу Event Log Readers.
- PT_Registry_Audit_Settings - политика настройки SACL для записи событий доступа к реестру.
- PT_DC_Audit_Settings - политика настройки контроллеров домена под аудит.
Параметры AAP для контроллеров домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- Включение аудита LDAP-запросов.
- PT_WS_Audit_Settings - политика настройки WS-хостов под аудит.
Параметры AAP для членов домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- PT_SRV_Audit_Settings - политика настройки Server-хостов под аудит.
Параметры AAP для членов домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- PT_Firewall_Rules - политика добавления Firewall правил.
- PT_WS_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на WS-хостах.
- PT_SRV_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на Server-хостах.
- PT_DC_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на DC-хостах.
Создание пользователей:
- Для сбора логов с хоста с дальнейшим добавлением в группу Event Log Readers.
- Для аудита системы с дальнейшим добавлением в группу локального администратора.
- Создание спец.группы для работы с пользователем сбора логов.
- PT_file_and_folder_Generic - политика настройки SACL для записи событий доступа к файлам и каталогам (Контроллеры и члены домена).
- PT_file_and_folder_SYSVOL - политика настройки SACL для записи событий доступа к файлам и каталогам (Контроллеры домена).
Пхпхпх... да... там нет Meta и нет описания зависимостей, ближе к полному релизу... допилю все по феншую😌
Еще новостей...
- На роль PT_LEP_Unix скоро заедет большой патч... в целом я надеюсь мы скоро сможем перейти на более удобную форму распространения ролей...
- В документации скоро появится еще парочка ролей которые я наклепал за все это время... а вероятно скоро увидим и вообще все... что было сделано за это время
Сейчас хоть не стыдно показать
Роль для настройки на источниках формата событий, правил журналирования, служб журналирования (rsyslog или syslog-ng) и отправки событий syslog через audispd.
Роль предназначена для добавления следующих политик на контроллерах домена (DC):
- PT_Event_LogReader - политика для сбора событий с целевых хостов, добавления группы MaxPatrol Group LogReader (в ней содержится пользователь под которым идет сбор логов) в локальную группу Event Log Readers.
- PT_Registry_Audit_Settings - политика настройки SACL для записи событий доступа к реестру.
- PT_DC_Audit_Settings - политика настройки контроллеров домена под аудит.
Параметры AAP для контроллеров домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- Включение аудита LDAP-запросов.
- PT_WS_Audit_Settings - политика настройки WS-хостов под аудит.
Параметры AAP для членов домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- PT_SRV_Audit_Settings - политика настройки Server-хостов под аудит.
Параметры AAP для членов домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- PT_Firewall_Rules - политика добавления Firewall правил.
- PT_WS_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на WS-хостах.
- PT_SRV_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на Server-хостах.
- PT_DC_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на DC-хостах.
Создание пользователей:
- Для сбора логов с хоста с дальнейшим добавлением в группу Event Log Readers.
- Для аудита системы с дальнейшим добавлением в группу локального администратора.
- Создание спец.группы для работы с пользователем сбора логов.
- PT_file_and_folder_Generic - политика настройки SACL для записи событий доступа к файлам и каталогам (Контроллеры и члены домена).
- PT_file_and_folder_SYSVOL - политика настройки SACL для записи событий доступа к файлам и каталогам (Контроллеры домена).
Пхпхпх... да... там нет Meta и нет описания зависимостей, ближе к полному релизу... допилю все по феншую
Еще новостей...
- На роль PT_LEP_Unix скоро заедет большой патч... в целом я надеюсь мы скоро сможем перейти на более удобную форму распространения ролей...
- В документации скоро появится еще парочка ролей которые я наклепал за все это время... а вероятно скоро увидим и вообще все... что было сделано за это время
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18❤🔥10🎉4
Каждый раз, когда я запускал роль для развертывания + конфигурации Linux VM, Ansible думает по 15 минут. А если нужно было поднять 10+ хостов - уходит час из жизни... SSH-сессии, перезагрузки модулей, простаивающие в очереди таски… пхпхпхпхп это не автоматизация, а психотерапия с таймером.. 😢
И кажется этот момент настал... порылся в гугле, перепробовал разные стратегии... и нашел наверное самое лучшее -> Mitogen - стратегия, которая ускоряет Ansible в 3 - 10 раз.
Почему это крутотень?
1) Одно SSH-соединение вместо тысячи - Ansible традиционно открывает новую сессию для каждой задачи Mitogen оставляет один канал открытым и гоняет через него все задачи.
2) Кэширование "на лету" - модули (типа copy или file) грузятся один раз, а не по 50.
3) Параллельность работает КАК И ДОЛЖНА РАБОТАТЬ - хосты не стоят в очереди... Mitogen динамически распределяет задачи между активными соединениями -> медленные серверы не тянут за собой все.
На самом деле поюзав этого зверя... я скостил разворачивание и конфигурацию хостов с 15-и минут аж до 6 на 1 хост, пачка и совсем за ~20 минут настраивается...
Есть конечно проблемки... Mitogen работает не на все модули, но кто нам мешает допилить😊
В общем... всем кто работает с Ansible, настоятельно рекомендую... да да
➡️ Github / Документация
И кажется этот момент настал... порылся в гугле, перепробовал разные стратегии... и нашел наверное самое лучшее -> Mitogen - стратегия, которая ускоряет Ansible в 3 - 10 раз.
Почему это крутотень?
1) Одно SSH-соединение вместо тысячи - Ansible традиционно открывает новую сессию для каждой задачи Mitogen оставляет один канал открытым и гоняет через него все задачи.
2) Кэширование "на лету" - модули (типа copy или file) грузятся один раз, а не по 50.
3) Параллельность работает КАК И ДОЛЖНА РАБОТАТЬ - хосты не стоят в очереди... Mitogen динамически распределяет задачи между активными соединениями -> медленные серверы не тянут за собой все.
На самом деле поюзав этого зверя... я скостил разворачивание и конфигурацию хостов с 15-и минут аж до 6 на 1 хост, пачка и совсем за ~20 минут настраивается...
Есть конечно проблемки... Mitogen работает не на все модули, но кто нам мешает допилить
В общем... всем кто работает с Ansible, настоятельно рекомендую... да да
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15👍4🔥3👀1
Сегодня с коллегой словили довольно занятный кейс 💃
Решили на Windows 11 24H2 (OS build 26100) снять дамп LSASS. Казалось бы - рутина, никаких сюрпризов. Отключаешь Defender, вырубаешь PPL и идёшь дальше жить спокойно
Но не тут-то было
Под админом - access denied
Ладно, думаем, может SeDebugPrivilege не хватило
Пробуем уже из под SYSTEM - там-то прав точно должно быть с запасом
И снова access denied😳 😳 😳 😳 😳
Вот тут я слегка приуныл...
На десятке с таким не сталкивался: базово отключил Defender + PPL - и LSASS дампится без плясок с бубном... а тут - внезапно стена.
Поковырялись, потыкались, и в итоге решил пойти по максимально злому пути:
"если непонятно, что именно мешает - проще снести всё к чертям, протестить, а потом откатить назад"🤣
В процессе наткнулся на вот такого зверя:
🤯 https://github.com/ionuttbara/windows-defender-remover
Инструмент, конечно, топорный, но задачу свою выполнил на отлично - после прогона дамп LSASS спокойно снялся
Вот такой любопытный кейс с Windows 11
Надо будет отдельно разобраться, что именно в 11-ой блокирует дамп даже при базовом отключении Defender и PPL - явно там что-то ещё под капотом, но вот что пока не очень понимаю😳
Решили на Windows 11 24H2 (OS build 26100) снять дамп LSASS. Казалось бы - рутина, никаких сюрпризов. Отключаешь Defender, вырубаешь PPL и идёшь дальше жить спокойно
Но не тут-то было
Под админом - access denied
Ладно, думаем, может SeDebugPrivilege не хватило
Пробуем уже из под SYSTEM - там-то прав точно должно быть с запасом
И снова access denied
Вот тут я слегка приуныл...
На десятке с таким не сталкивался: базово отключил Defender + PPL - и LSASS дампится без плясок с бубном... а тут - внезапно стена.
Поковырялись, потыкались, и в итоге решил пойти по максимально злому пути:
"если непонятно, что именно мешает - проще снести всё к чертям, протестить, а потом откатить назад"
В процессе наткнулся на вот такого зверя:
Инструмент, конечно, топорный, но задачу свою выполнил на отлично - после прогона дамп LSASS спокойно снялся
Вот такой любопытный кейс с Windows 11
Надо будет отдельно разобраться, что именно в 11-ой блокирует дамп даже при базовом отключении Defender и PPL - явно там что-то ещё под капотом, но вот что пока не очень понимаю
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍6🤔3☃1
Forwarded from Мишка на сервере (Mikhail Savin)
SREGame: живой CTF по SRE вместо скучных учебников
Привет,
Вместо симуляций тебе дают доступ к настоящему окружению: лезешь в конфиги, смотришь логи и трафик, ищешь флаги, разбираешься, почему всё упало и как это починить. По сути, это CTF в формате «боевых дежурств»: меньше теории, больше реального hands-on, который можно потом конвертировать в улучшения своих процессов, алертов и runbook’ов.
Такой формат отлично заходит:
- SRE/DevOps, которые хотят прокачать навыки расследования инцидентов без боли продакшена.
- Тимлидам и техлидам, которым нужен практический тренажёр для команды вместо абстрактных тренингов.
- Инженерам эксплуатации, которые хотят потренироваться «копать глубже»: от сети и конфигураций до приложений и инфраструктуры.
Мне нравится идея использовать подобный сервис как внутренний «полигон»: можно устраивать регулярные CTF-сессии, отрабатывать on-call сценарии, шлифовать процессы эскалации и совместно улучшать документацию и знания команды.
А как ты учишь команду разбирать инциденты: разборы полётов на сухих постмортемах или практические разборы в песочнице? Хотел(а) бы поучаствовать в таком SRE CTF сам(а) или дать его джунам/мидлам как часть онбординга? Какие форматы «боевого» обучения SRE тебе заходят лучше всего и почему?
#SRE #DevOps #OnCall #Incidents #CTF #Education #SREGame
Привет,
%username%! Если тебе надоели теоретические статьи про SRE и хочется «потрогать прод» без риска всё уронить, обрати внимание на SREGame — сервис с живым sandbox-окружением, где ты расследуешь инциденты как в реальной жизни.Вместо симуляций тебе дают доступ к настоящему окружению: лезешь в конфиги, смотришь логи и трафик, ищешь флаги, разбираешься, почему всё упало и как это починить. По сути, это CTF в формате «боевых дежурств»: меньше теории, больше реального hands-on, который можно потом конвертировать в улучшения своих процессов, алертов и runbook’ов.
Такой формат отлично заходит:
- SRE/DevOps, которые хотят прокачать навыки расследования инцидентов без боли продакшена.
- Тимлидам и техлидам, которым нужен практический тренажёр для команды вместо абстрактных тренингов.
- Инженерам эксплуатации, которые хотят потренироваться «копать глубже»: от сети и конфигураций до приложений и инфраструктуры.
Мне нравится идея использовать подобный сервис как внутренний «полигон»: можно устраивать регулярные CTF-сессии, отрабатывать on-call сценарии, шлифовать процессы эскалации и совместно улучшать документацию и знания команды.
А как ты учишь команду разбирать инциденты: разборы полётов на сухих постмортемах или практические разборы в песочнице? Хотел(а) бы поучаствовать в таком SRE CTF сам(а) или дать его джунам/мидлам как часть онбординга? Какие форматы «боевого» обучения SRE тебе заходят лучше всего и почему?
#SRE #DevOps #OnCall #Incidents #CTF #Education #SREGame
❤🔥7🔥2
Сегодня со мной произошло маленькое профессиональное "чудо" 🫠
Я наконец-то применил знания, полученные на сертификации RHCSA… спустя 6 лет
Иногда кажется, что половина того, что учишь, так и останется «на всякий случай».
А потом наступает тот самый рабочий кейс - и ты понимаешь, зачем всё это было😳
🟠 Притча о том, как я RAID воскрешал (почти)
Я наконец-то применил знания, полученные на сертификации RHCSA… спустя 6 лет
Иногда кажется, что половина того, что учишь, так и останется «на всякий случай».
А потом наступает тот самый рабочий кейс - и ты понимаешь, зачем всё это было
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥19❤8👏3🤩1🐳1
Хочу в 4 утра поделится с вами двумя вещицами:
🔊 Awesome Black Hat Arsenal
По сути это такой "священный свиток тёмной магии", только без необходимости смотреть трёхчасовой доклад с Black Hat, где чувак в худи с видом «я сейчас переверну индустрию» в конце слайда невнятно показывает ссылку на GitHub.
Это "awesome-list" для red team / pentest / exploit dev, аккуратно собранный из тулзов, которые всплывали на конференциях Black Hat.
То есть вместо сценария:
"О боже, Кенни, он опять выложил "революционный" фреймворк!"
- Погнали вручную перебивать ссылку с YouTube, пока автор листает слайд 0.7 секунды.
Ты получаешь:
"О, смотри, уже всё собрано... категории есть... инструменты есть... ссылки кликабельные (но не все😏 )... можно жить."
🪟 CVE2CAPEC
Тут мне если честно лень придумывать такое же красивое описание... поэтому я просто дам идею и описание тулы... как я это юзаю.
CVE2CAPEC - это утилита/датасет для сопоставления уязвимостей из базы MITRE с шаблонами атак CAPEC.
Идея тут такая - перевести конкретную уязвимость (CVE) в более общий "паттерн атаки" (CAPEC), чтобы понять к какому классу атак она относится.
Юзал для составления сценариев... вроде даже помогало.
По сути это такой "священный свиток тёмной магии", только без необходимости смотреть трёхчасовой доклад с Black Hat, где чувак в худи с видом «я сейчас переверну индустрию» в конце слайда невнятно показывает ссылку на GitHub.
Это "awesome-list" для red team / pentest / exploit dev, аккуратно собранный из тулзов, которые всплывали на конференциях Black Hat.
То есть вместо сценария:
"О боже, Кенни, он опять выложил "революционный" фреймворк!"
- Погнали вручную перебивать ссылку с YouTube, пока автор листает слайд 0.7 секунды.
Ты получаешь:
"О, смотри, уже всё собрано... категории есть... инструменты есть... ссылки кликабельные (но не все
Тут мне если честно лень придумывать такое же красивое описание... поэтому я просто дам идею и описание тулы... как я это юзаю.
CVE2CAPEC - это утилита/датасет для сопоставления уязвимостей из базы MITRE с шаблонами атак CAPEC.
Идея тут такая - перевести конкретную уязвимость (CVE) в более общий "паттерн атаки" (CAPEC), чтобы понять к какому классу атак она относится.
Юзал для составления сценариев... вроде даже помогало.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13😭2
Довольно долго практикую такую вещь - выкладываю все мысли на бумагу или схемы
Очень круто помогает разгружать мозги.
Один знакомый тут заметил у меня заметочки в обсидиане... попросил выкидывать в какую-то группу.
Без понятия чем это может быть кому-то полезно, но держите, мало ли интересно.
➡️ Link
Сюда это писать не хочется, ибо кажется, что совсем не формат.
Очень круто помогает разгружать мозги.
Один знакомый тут заметил у меня заметочки в обсидиане... попросил выкидывать в какую-то группу.
Без понятия чем это может быть кому-то полезно, но держите, мало ли интересно.
Сюда это писать не хочется, ибо кажется, что совсем не формат.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13💩1🐳1
Forwarded from Golden HackSpace | Hacker notes
🔥 Ludus: Автоматизация деплоя лабораторных сред
Ludus — инструмент для создания автоматизированных лабораторных сред. Позволяет быстро разворачивать и управлять тестовыми средами для практики атак.
🌐 Официальный сайт
📦 GitLab
📚 Руководства
Связанные проекты Ludus:
1. LudusHound
Позволяет реплицировать инфраструктуру, используя данные из BloodHound.
https://specterops.io/blog/2025/07/14/ludushound-raising-bloodhound-attack-paths-to-life/
https://github.com/bagelByt3s/LudusHound
2. Деплой C2 в Ludus
C2-сервер для использования в лабораторных средах.
https://github.com/badsectorlabs/ludus_adaptix_c2
https://github.com/0xRedpoll/ludus_cobaltstrike_teamserver
3. Специализированные лаборатории
Специализированные лаборатории для изучения атак на отдельные сервисы.
SCCM: https://github.com/Synzack/ludus_sccm
ADCS: https://github.com/badsectorlabs/ludus_adcs
SCOM: https://github.com/Synzack/ludus_scom
#lab #ludus #redteam
Ludus — инструмент для создания автоматизированных лабораторных сред. Позволяет быстро разворачивать и управлять тестовыми средами для практики атак.
🌐 Официальный сайт
📦 GitLab
📚 Руководства
Связанные проекты Ludus:
1. LudusHound
Позволяет реплицировать инфраструктуру, используя данные из BloodHound.
https://specterops.io/blog/2025/07/14/ludushound-raising-bloodhound-attack-paths-to-life/
https://github.com/bagelByt3s/LudusHound
2. Деплой C2 в Ludus
C2-сервер для использования в лабораторных средах.
https://github.com/badsectorlabs/ludus_adaptix_c2
https://github.com/0xRedpoll/ludus_cobaltstrike_teamserver
3. Специализированные лаборатории
Специализированные лаборатории для изучения атак на отдельные сервисы.
SCCM: https://github.com/Synzack/ludus_sccm
ADCS: https://github.com/badsectorlabs/ludus_adcs
SCOM: https://github.com/Synzack/ludus_scom
#lab #ludus #redteam
🤔2🐳1
Forwarded from Мишка на сервере (Mikhail Savin)
Почему 100% Uptime — это иллюзия, и при чем тут демон Лапласа?
Привет,
Пьер-Симон Лаплас придумал гипотетическое существо (сверхразум), которое в любой момент времени знает точное положение и скорость абсолютно каждого атома во Вселенной, а также все действующие на них силы. Обладая такими данными, этот демон мог бы безошибочно предсказывать будущее. В его мире нет случайностей, только строгая закономерность.
Так вот, чтобы гарантировать 100% Uptime сложной распределенной системы, инженеру нужно буквально стать таким демоном Лапласа. Тебе пришлось бы заранее знать:
- Точное состояние каждого транзистора, диска и кулера на тысячах серверов;
- Маршрут и судьбу каждого сетевого пакета от мобилки пользователя до твоего балансировщика;
- Любую, даже самую безумную комбинацию пользовательского ввода;
- Случайные космические лучи, меняющие биты в памяти (bit flip), и вероятность того, что пьяный экскаваторщик перерубит магистральный кабель провайдера.
Поскольку мы не обладаем всеведением, в наших системах всегда живет хаос. В физике квантовая механика давно доказала, что демон Лапласа невозможен из-за принципа неопределенности. В нашей профессии аналогом этого закона выступает простая истина: сбои неизбежны, а энтропия всегда растет.
Именно поэтому в SRE мы осознанно отказываемся от идеи 100% надежности:
- Мы устанавливаем реалистичные SLO (например, 99.9%), чтобы честно зафиксировать допустимый уровень отказов и не обманывать ни себя, ни клиентов;
- Мы используем Error Budgets, признавая, что оставшиеся доли процента — это легальное пространство для хаоса, а также наш бюджет на релизы и эксперименты;
- Вместо попыток предвидеть вообще всё, мы строим устойчивые к отказам системы и снижаем MTTR, чтобы падать безопасно и восстанавливаться быстро.
Отказ от 100% Uptime — это не инженерная слабость. Это зрелое понимание законов природы и устройства сложных систем.
А как у тебя обстоят дела с ожиданиями бизнеса? Приходилось ли тебе отговаривать стейкхолдеров от SLA в 100% и какие аргументы ты для этого использовал? Какой самый непредсказуемый сбой или "черный лебедь" разрушил твой идеальный аптайм? Делись историями в комментариях!
#SRE #DevOps #Observability #incidents #ErrorBudget #SLO #SiteReliabilityEngineering #Architecture
Привет,
%username%! В работе SRE и при проектировании систем часто приходится сталкиваться с утопичным требованием бизнеса: «Наш сервис должен работать всегда, нам нужен 100% SLA». Звучит как отличная амбициозная цель, но на практике она недостижима. И чтобы изящно объяснить почему, отлично подходит мысленный эксперимент из начала XIX века — концепция демона Лапласа.Пьер-Симон Лаплас придумал гипотетическое существо (сверхразум), которое в любой момент времени знает точное положение и скорость абсолютно каждого атома во Вселенной, а также все действующие на них силы. Обладая такими данными, этот демон мог бы безошибочно предсказывать будущее. В его мире нет случайностей, только строгая закономерность.
Так вот, чтобы гарантировать 100% Uptime сложной распределенной системы, инженеру нужно буквально стать таким демоном Лапласа. Тебе пришлось бы заранее знать:
- Точное состояние каждого транзистора, диска и кулера на тысячах серверов;
- Маршрут и судьбу каждого сетевого пакета от мобилки пользователя до твоего балансировщика;
- Любую, даже самую безумную комбинацию пользовательского ввода;
- Случайные космические лучи, меняющие биты в памяти (bit flip), и вероятность того, что пьяный экскаваторщик перерубит магистральный кабель провайдера.
Поскольку мы не обладаем всеведением, в наших системах всегда живет хаос. В физике квантовая механика давно доказала, что демон Лапласа невозможен из-за принципа неопределенности. В нашей профессии аналогом этого закона выступает простая истина: сбои неизбежны, а энтропия всегда растет.
Именно поэтому в SRE мы осознанно отказываемся от идеи 100% надежности:
- Мы устанавливаем реалистичные SLO (например, 99.9%), чтобы честно зафиксировать допустимый уровень отказов и не обманывать ни себя, ни клиентов;
- Мы используем Error Budgets, признавая, что оставшиеся доли процента — это легальное пространство для хаоса, а также наш бюджет на релизы и эксперименты;
- Вместо попыток предвидеть вообще всё, мы строим устойчивые к отказам системы и снижаем MTTR, чтобы падать безопасно и восстанавливаться быстро.
Отказ от 100% Uptime — это не инженерная слабость. Это зрелое понимание законов природы и устройства сложных систем.
А как у тебя обстоят дела с ожиданиями бизнеса? Приходилось ли тебе отговаривать стейкхолдеров от SLA в 100% и какие аргументы ты для этого использовал? Какой самый непредсказуемый сбой или "черный лебедь" разрушил твой идеальный аптайм? Делись историями в комментариях!
#SRE #DevOps #Observability #incidents #ErrorBudget #SLO #SiteReliabilityEngineering #Architecture
👍5❤3👎2🔥1🐳1
Боже, как мне надоело, что про этот ИИ вокруг все говорят и говорят...
Куда ни зайдешь - везде одно и то же: "ИИ заменит админов", "ИИ напишет всё за тебя","ИИ теперь DevOps", "ИИ умеет в Ansible лучше людей".
И каждый раз звучит так, будто завтра можно просто отдать ему доступы в прод и уйти пить кофе😏
Но тут попалось видео Learn Linux TV, где автор нормально проверяет Claude Code на реальном Ansible-проекте.
Не на игрушечном "установи nginx" (кто-то вообще на других примерах ansible показывает?!!), а на более менее приемлемой домашней лаборатории.
И вот тут стало интереснее... я посмотрел на это все... и решил повторить на своей домашней инфре😳
Claude Code реально смог разобраться в структуре проекта, понять, где что лежит, предложить изменения, поправить существующие playbookи и в целом вести себя не как генератор случайного YAML, а как помощник, который умеет копаться в кодовой базе, ну и README он хорошо написал по моему шаблону.
Но магии, конечно, не случилось.
В какой-то момент он попытался создать новый playbook для того, что уже было реализовано в проекте... то есть классическая история... вроде умный, вроде помогает, но без ревью может наделать лишнего или вообще увести не туда.
И, честно, вывод такой: ИИ - это не замена системному администратору и не волшебная кнопка "сделай инфраструктуру".
Это скорее очень быстрый джун, которому можно дать задачу, но потом обязательно проверить, что он там наворотил☕️
Для Ansible, рефакторинга, поиска по проекту, черновиков задач и рутины - да, полезно...
Для "вот тебе прод, делай что хочешь, лишь бы оно работало" - нет, спасибо, я еще жить хочу...
Короче, ИИ не отменяет знания... он просто делает боль чуть менее больной, если рядом есть человек, который понимает, что именно надо проверить.
Связка понимающий специалист + AI агент - выглядит очень мощно
Связка джун + AI агент - выглядит очень и очень опасно для всего, до чего дотянется AI агент
Недавно еще получил доступ к AIOps от RHEL, потыкаюсь... может мнение изменится в лучшую сторону... но пока ощущение черного ящика никуда не уходит...
p.s. но ai-connect от ansible, действительно удобная штука... тут придраться сложно, так что всем кто активно юзает ansible - рекомендую
Куда ни зайдешь - везде одно и то же: "ИИ заменит админов", "ИИ напишет всё за тебя","ИИ теперь DevOps", "ИИ умеет в Ansible лучше людей".
И каждый раз звучит так, будто завтра можно просто отдать ему доступы в прод и уйти пить кофе
Но тут попалось видео Learn Linux TV, где автор нормально проверяет Claude Code на реальном Ansible-проекте.
Не на игрушечном "установи nginx" (кто-то вообще на других примерах ansible показывает?!!), а на более менее приемлемой домашней лаборатории.
И вот тут стало интереснее... я посмотрел на это все... и решил повторить на своей домашней инфре
Что я понял?
Claude Code реально смог разобраться в структуре проекта, понять, где что лежит, предложить изменения, поправить существующие playbookи и в целом вести себя не как генератор случайного YAML, а как помощник, который умеет копаться в кодовой базе, ну и README он хорошо написал по моему шаблону.
Но магии, конечно, не случилось.
В какой-то момент он попытался создать новый playbook для того, что уже было реализовано в проекте... то есть классическая история... вроде умный, вроде помогает, но без ревью может наделать лишнего или вообще увести не туда.
И, честно, вывод такой: ИИ - это не замена системному администратору и не волшебная кнопка "сделай инфраструктуру".
Это скорее очень быстрый джун, которому можно дать задачу, но потом обязательно проверить, что он там наворотил
Для Ansible, рефакторинга, поиска по проекту, черновиков задач и рутины - да, полезно...
Для "вот тебе прод, делай что хочешь, лишь бы оно работало" - нет, спасибо, я еще жить хочу...
Короче, ИИ не отменяет знания... он просто делает боль чуть менее больной, если рядом есть человек, который понимает, что именно надо проверить.
Связка понимающий специалист + AI агент - выглядит очень мощно
Связка джун + AI агент - выглядит очень и очень опасно для всего, до чего дотянется AI агент
Недавно еще получил доступ к AIOps от RHEL, потыкаюсь... может мнение изменится в лучшую сторону... но пока ощущение черного ящика никуда не уходит...
p.s. но ai-connect от ansible, действительно удобная штука... тут придраться сложно, так что всем кто активно юзает ansible - рекомендую
Please open Telegram to view this post
VIEW IN TELEGRAM
❤21😢6🔥1🐳1
Пришли ко мне с одной задачкой... ну я за неё и сел... ☕️
Обожаю Windows, обожаю ACL, обожаю права, обожаю атрибуты, обожаю моменты, когда ты вроде бы всё понял, а потом AD такая:
"Не-не-не, ты понял не всё старина"
Разбирался с dMSA при тестировании BadSuccessor-like сценариев и внезапно уперся в очень показательный нюанс... в общем вот..
🟠 Притча о том, как я разбирался с dMSA при тестировании BadSuccessor-like сценариев
Обожаю Windows, обожаю ACL, обожаю права, обожаю атрибуты, обожаю моменты, когда ты вроде бы всё понял, а потом AD такая:
"Не-не-не, ты понял не всё старина"
Разбирался с dMSA при тестировании BadSuccessor-like сценариев и внезапно уперся в очень показательный нюанс... в общем вот..
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5❤🔥2👍1🔥1🤣1
24 июля в 15:30 в Московском офисе Positive Technologies пройдет митап для начинающих специалистов. Это возможность познакомиться с коллегами Позитива, различными направлениями в компании и послушать реальный опыт коллег.
В программе:
➡️ Владимир Николаев, эксперт PT Lab, погрузит во внутрянку агентов Caldera
➡️ Андрей Михайлов, младший инженер PT Lab, расскажет, как создаются лабораторные стенды для практики
➡️ Евгений Копытин, специалист отдела анализа защищенности веб-приложений, раскроет полный потенциал SSRF
➡️ Приглашенный Спикер и тема останутся сюрпризом 🫥
А еще будет экскурсия по офису, пицца, призы за лучшие вопросы и неформальное общение🍕
Заполни форму регистрации по ссылке, если собираешься прийти
До встречи на митапе!🙂
В программе:
А еще будет экскурсия по офису, пицца, призы за лучшие вопросы и неформальное общение
Заполни форму регистрации по ссылке, если собираешься прийти
🟥 Важно: количество мест ограничено, после регистрации дождись письма с подтверждением участия и подробностями мероприятия
До встречи на митапе!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👎1
Для тех кто пропустил наш митап 😁
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ITAM
Готов прокачать скиллы в практической безопасности и узнать, как работают топовые эксперты индустрии? Открываем новый сезон мощным митапо, только разборы реальных кейсов и карьерный трек в ИБ.
Что тебя ждёт?
Здесь вы точно найдете что-то интересное для себя
Артемий Цецерский, амбассадор Standoff, эксперт отдела исследования киберугроз в Angara Security
Иван Булавин, директор платформы Standoff
Владимир Николаев, руководитель команды PTLab Positive Technologies, капитан команды BinaryBears
Андрей Кавыкин, руководитель подгруппы управления событиями ИБ Ozon
Не упусти шанс прокачаться в кибербезопасности и лично пообщаться с экспертами.
Регистрация для внешних участников доступна по ссылке. А также не забудь захватить с собой паспорт. Студентам Университета МИСИС регистрироваться не нужно.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6