Сергей Озеранский

На фоне очередного инцидента в GitHub, вспомнил о существовании интересного ресурса https://mrshu.github.io/github-statuses/ Это более подробная информация о статусе GitHub сервисов, чем та, что на официальном https://www.githubstatus.com/ Кому-то будет возможно полезно. Этот ресурс из интеренсо показывает реальный SLA. И, по моему мнению, это крайне низкий показатель https://uptime.is/86.75 И еще, "забавный" факт https://damrnelson.github.io/github-historical-uptime/ Этот график показывает Uptime GitHub до покупки их Microsoft и после. Даже не знаю какой вывод сделать 😳🙈

Я очень долго ждал этой фичи в Grafana. Я люблю декларативный подход в описании конфигураций и всего остального. Изъясняться as code намного проще, полезнее и даже безопаснее, чем "накликивать" что-то в UI. И так уж сложилось, что в Grafana годами не было нативного адекватного способа работы с декларативным описанием дашбордов. Да, был экспорт в JSON, и его можно было руками сохранять в Git, но это не решало проблему единого источника правды и не помогало в части декларативности описания конфигурации дашборда. Несколько лет назад я искал инструменты, чтобы иметь возможность описывать дашборды на том же Python, и находил что-то, но выглядело это как нечто экспериментальное и не особо активно развивающееся. Сейчас мы приблизились к решению - Grafana Foundation SDK и Git Sync. Очень интересно.

Стало интересно "пузомеркой" (олды слово вспомнят) помериться 😅 Возьмите свой самый большой сервис и напишите в коментариях • кол-во тестов (параметризиация считается), то есть сколько тестов реально выполняется за прогоц всего, всех. • время за которое прогоняются все тесты у вас на машине. Предполагаю что это в среднем MacBook Pro 2-3 летней давности.

Как мой шестилетний сын подобрался к семафорам Пекли сегодня с сыном (6 лет) пирожки с разными начинками (важно для контекста). Сели есть. Он показывает мне конфету и читает по обертке название - "Semaphor". Меня триггернуло флешбеками (*мем про собаку и Вьетнамские флешбеки*), и я говорю: "Слушай, а ведь в программировании тоже есть семафоры". Он подумал секунду и выдает: "Пап, а давай я угадаю, зачем они нужны". Я: "Давай." Далее ответ шестилетки: "Если у вас что-то идет, в программировании, чтобы это попало в нужное место назначения. И чтобы другое прошло, они ждут то, что надо, чтобы прошло. Ну, например, чтобы изюм попал в пирожок, а слива - в сырник. Чтобы не попало изюм в сырник, а слива в пирожок - вот для этого семафоры." Я сначала сказал: "Ну, сигнал от семафора ждут, да, ты прав". А потом, пока мы продолжали разговор и уже рефлексируя над его мыслями, я начал понимать, что все не так просто. Что описал ребенок. Он самостоятельно, хоть и имея уже за плечами свой первый "Hello, World!" (на Python, конечно же) за плечами, он пришел к идее, что в программе что-то может кого-то ждать. Человек приоткрыл дверь в в мир конкурентности, и он ее открыл сам. Конкретно его метафора, про изюм в пирожок и сливу в сырник, это скорее маршрутизация: каждому ингредиенту свое изделие, каждый едет своей дорогой. В коде это две независимые очереди, и они физически не пересекаются. Семафор тут формально не нужен, но интуиция "что-то должно следить, чтобы все попало куда надо" как раз семафорная по духу. Он почувствовал задачу раньше, чем научился ее точно формулировать, а это, честно говоря, и трудная задача в программировании. Где тут семафор живет по-настоящему. Я попробовал поправить: "Тут скорее, чтобы слива попала по своей очередности в пирожок в тот же, куда попадал изюм". То есть пирожок один, и изюм со сливой оба хотят в него попасть - нужна очередность, кто-то первый, кто-то ждет. Это уже ближе: один общий ресурс, несколько претендентов, правило доступа. Это мьютекс (семафор со счетчиком 1). А если развернуть дальше, то N одинаковых ресурсов и M претендентов, где M > N. Десять пирожков на столе, пятьдесят ягод рвутся внутрь. Пускаем по десять за раз, остальные ждут. Вот это уже полноценный семафор Дейкстры со счетчиком больше единицы. Классический пример в реальном коде это пул из десяти коннекшенов к базе и пятьдесят воркеров, которые эти коннекшены честно делят. Мы с ним по сути прошли путь от интуиции к определению за один разговор на кухне. Он задал верное направление, "что-то ждет, чтобы не было путаницы", а точная модель (одно место, несколько претендентов, очередность) дошла уже дальше при рассуждениях.

🛡️ httptap получил OpenSSF Best Practices Silver Это не просто галочка. OpenSSF (при Linux Foundation) это те ребята, что следят за безопасностью на уровне всего opensource. Silver - средний из трех тиров (passing -> silver -> gold), и чтобы его получить пришлось закрыть 43 критерия поверх 67 passing-уровня. Gold solo-мейнтейнером структурно не берется, так как нужны 2+ активных reviewer'а. Что конкретно сделано - SBOM на каждом релизе (CycloneDX + SPDX), вы видите все зависимости прямо в GitHub Release - SLSA v1.0 build provenance через Sigstore keyless signing, можно проверить артефакт: gh attestation verify httptap-*.whl --repo ozeranskii/httptap - Отсутствует долгоживущий PyPI-токен - OIDC Trusted Publishing, подпись приходит из GitHub, а не лежит в секретах - Все actions в workflows запиннены по SHA (zizmor pedantic в CI блокирует любой unpinned action) - Published threat model (https://docs.httptap.dev/security/assurance-case/) - STRIDE-разбор, trust boundaries, 17 countered CWE, residual risks - GOVERNANCE.md, ROADMAP.md, SECURITY.md - описание кто мейнтейнит, как принимаются решения, continuity plan, план реакции на уязвимости (+ VEX-документ прикладывается к релизам) Зачем это вам Если вы подтаскиваете httptap в корпоративный CI или docker-образ, то комплаенс-вопросы снимаются разом: - CRA-ready (EU Cyber Resilience Act), NIST SSDF-совместимо - OpenSSF Scorecard: ~7.6/10 (структурно выше без соавтора уже не поднять) - Попутно получен OpenSSF Baseline-3 - еще один фреймворк, более регуляторный Пройденные уровни - Passing (67 критериев) → https://www.bestpractices.dev/en/projects/12474/passing - Silver (текущий уровень) → https://www.bestpractices.dev/en/projects/12474/silver - Scorecard → https://scorecard.dev/viewer/?uri=github.com/ozeranskii/httptap - Assurance case → https://docs.httptap.dev/security/assurance-case/ Мне было интересно пройти этот путь, так как я кое-чему научился. А еще подтвердил, что в целом проекте многие пункты уже закрывал автоматически, так как бОльшая часть была уже сделана ранее. То есть сам проект уже писался в парадигме лучших DevSecOps практик.

🚀 httptap 0.5.0 и новая --slo фича Закрыл пробел функциональности: httptap теперь не просто показывает, где деградировал latency, а может фейлить pipeline на нарушении бюджета. Один флаг в команде httptap и latency становится частью CI-gate'а.

    
        
httptap --slo total=500,ttfb=200 https://api.example.com/health
{}
    

Уложились -> exit 0. Деградировали -> exit 4 + полный отчет видно какая фаза убила бюджет. 6 сценариев применения (примеры примитивны, важна идея) 1. Smoke-тест после деплоя в - run: httptap --slo total=2000,tls=300,ttfb=800 https://staging.example.com/ 2. Kubernetes readiness probe

    
        
  readinessProbe:
    exec:
      command: [httptap, --slo, "total=5000", "http://localhost:8080/healthz"]
{}
    

Pod принимает трафик, пока реально не отвечает за требуемое время. 3. Synthetic monitoring cron

    
        
  * * * * * httptap --slo total=1000,ttfb=500 https://api/health \
    || curl -X POST https://alerts/page/oncall
{}
    

On duty просыпается когда latency деградировала, до того, как пользователи начнут жаловаться. 4. Замерили нормальную p95-latency один раз (скажем, 450ms), вшили как --slo total=450 в CI и теперь любой PR, который замедлил endpoint, краснеет автоматически, до того как медленный код доедет до прода. 5. Canary-сравнение по регионам

    
        
  for host in prod-eu prod-us prod-ap; do
    httptap --slo total=1500 "https://${host}.example.com/api" \
      || echo "${host}: SLA miss"
  done
{}
    

Мгновенно видно, какой регион отваливается от SLO. 6. Dependency health в CI Когда ваш сервис зависит от внешнего API, то добавьте httptap --slo total=X этого API в мониторинг. Падение upstream'а вы заметите по алертам мониторинга еще до того, как он повлияет на прод. Что ещe приехало с релизом • Per-phase budgets --slo dns=50,connect=100,tls=300,ttfb=500,total=1000. Не только total. • Точная диагностика: total: 723.4ms > 500ms (+223.4ms), видно не просто деградировали, а на сколько именно. • Совместимость с httpstat: exit 4 и токены slo=pass/fail специально совпадают. Зачем вам это, если у вас есть APM? APM показывает что было. SLO-gate блокирует чтобы не стало. Прод не падает из-за того, что метрика красная в APM, прод падает, потому что медленный код доехал до прод-релиза или есть медленные зависимости API. --slo в CI это linting для latency. PR: https://github.com/ozeranskii/httptap/pull/118

И да, мы люди, нам тяжело удерживать эти правила в голове, это нормально. Поэтому существуют инструменты, которые нам помогают не забывать. Это такие инструменты как разного рода линтеры, чекеры и аудиторы. Они как раз и закрывают эту проблему. Вот, например, интересный инструмент для статического анализа GitHub Actions: https://github.com/zizmorcore/zizmor https://docs.zizmor.sh/ И в нем как раз есть правило https://docs.zizmor.sh/audits/#dependabot-cooldown про тот самый dependency cooldown. Я zizmor пока не пробовал, но планирую его попробовать на https://github.com/ozeranskii/httptap

Есть правила безопасной разработки. Базово овладев (а это значит — понять и применять) OWASP Top 10, уже можно говорить, что у вас есть базовый уровень DevSecOps. У меня был доклан на PiterPy 2023 по теме "Векторы атак: взгляд разработчика". Хоть сам TOP и обновился с 2023 года, доклад не теряет актуальности. Сами проблемы не куда не деваются, они приоритезируются и добавляются новые или происходит объединением их в новую категорию. Рекомендую посмотреть доклад https://t.me/sergeiozeranskii/29 Это не что-то новое. Я часто говорю, что за нас уже давно многое придумано, и нам стоит просто переиспользовать практики. А практик много: — DevOps — DevSecOps — системный дизайн — теория программирования — etc... Они обширные, да. Но если понять проблему и правильно задавать вопросы, то нужную практику вы либо найдете, либо найдете того, кто ей владеет и сможет помочь. Но даже при этом всем люди все еще совершают, казалось бы, типичные ошибки. (И у меня бывает, я тоже человек.) Только вот цена ошибок разная. О каких ошибках я говорю, вот пример: https://t.me/sergeiozeranskii/480 Если порефлексировать, пользователи Trivy совершили две ошибки. Первая и она очевидная. Отсутствие фиксации зависимости через digest. Что такое digest? Это когда зависимость фиксируется не просто по номеру версии, а еще и проверяется hash-сумма. Если она не совпадает, то зависимость не ставится и пайплайн падает. Вторая, менее очевидная ошибка. Отсутствие dependency cooldown. Суть очень простая: не тянуть свежевышедшие версии зависимостей сразу. Дать им “отлежаться”, как новой куртке, которую вы купили. Как это могло спасти? Если бы старые версии не были затронуты (как это часто и бывает), то те, у кого есть dependency cooldown, просто не обновились бы сразу и спокойно переждали. А те, у кого его нет: получили уведомление о новой версии → обновились → втащили уязвимую зависимость. Просто потому что побежали впереди паровоза и взяли версию, которую еще не успело провалидировать комьюнити. И даже не всегда дело в уязвимостях. Любая зависимость может: — иметь баги — быть несовместимой Ей нужно время “отлежаться”. Я, например, когда выходит новый Python, жду 1–2 патч-версии, прежде чем тащить его в прод. К слову об OWASP: https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/ И тут все уже, как я писал про практики, описано. Бери и делай. Я бы сюда еще добавил идею из: https://owasp.org/Top10/2025/A06_2025-Insecure_Design/ Про “не доверяй никому”. Потому что все люди, и все ошибаются. Даже в условном Google в OSS могут появляться сомнительные или небезопасные изменения. В итоге dependency cooldown это просто задержка. Например: — не брать версии младше N дней — или фиксировать версии и обновлять их вручную с лагом И ты автоматически пропускаешь значительную часть таких атак. Важно: это не серебряная пуля. Но это дешевый и эффективный фильтр от булшита.