MashaOps

Интересный новый проект от Cloudflare - опен-сорсная "операционная система", заточенная под кастомизацию под конкретную компанию (какие MCP доступны, безопасность и политики, стандартные флоу работы и тд) Официальный анонс в блоге: https://blog.cloudflare.com/cloudflare-os/ Лендинг: https://os.cloudflare.app/ Репозиторий на гитхабе: https://github.com/cloudflare/cloudflare-os

В статье How LLMs actually work автор объясняет все ключевые шаги обработки промта. Очень полезно и по большей части доступно, советую к прочтению всем, кто активно работает с LLM.

По работе пришлось поресерчить на тему NUMA (=Non-uniform memory access) нод. Хороший доклад с одного из Кубконов по теме: https://youtu.be/C6aBa1vnYT4?si=98mHD_7CxliKT855 Чтобы больше погрузится в тему в разрезе Kubernetes, советую почитать: 1. KEP-1769: Memory Manager 2. Control Memory Management Policies on a Node 3. Control Topology Management Policies on a node

Красивый лендинг по поводу самоуправляемых кодовых баз https://background-agents.com/ У нас такого еще нет, но можно ассайнить таски на Copilota - он сам заберет всю информацию из таски, проанализует кодовую базу и сделает пулл реквест. Инженеру не нужно…

Написала небольшую статью про последние видео и статьи по теме AI и Github Copilot CLI, которые мне показались интересными и полезными(доступна и на английском). В последнее время так много контента, что хотелось бы продолжать и дальше собирать такие дайджесты.…

Написала небольшую статью про последние видео и статьи по теме AI и Github Copilot CLI, которые мне показались интересными и полезными(доступна и на английском). В последнее время так много контента, что хотелось бы продолжать и дальше собирать такие дайджесты. 🚀 На следующей неделе поделюсь своим опытом из только закончившегося Kubecon в Амстердаме. Ну и надеюсь, что смогу отсмотреть часть докладов (их уже начали выкладывать на официальный Youtube канал) и поделиться моими самыми любимыми. P.S. Для написания этого поста мы с копилотом полностью обновили весь блог и даже ничего не сломали 😅

Наткнулась на интересную статью: I Don’t Care What You Build (And Neither Should You) Автор рассуждает на тему успешности дизайн изменений и что на самом деле нужно фокусироваться на том, как узнать, что мы достигли успеха. Один из примеров фреймворка (очень похоже на работу с AI агентами в том числе, так как они помогают очень быстро итерироваться по первым пяти пунктам): • Observation — look at data • Annotate and build evaluations — define what “good” and “bad” look like • Hypothesise — understand the why • Design and run experiments — test the hypothesis • Measure outcomes — did it work? • Apply and iterate На моем опыте это довольно частая проблема - дизайн документы довольно часто фокусируются на текущих проблемах и как используя новые инструменты и технологии их устранить. Иногда все действительно упирается в плохое решение, которые было принято в силу "historical reasons", но почему-то очень редко пишут, какие конкретно цели хотят достичь. Тоже самое касается разбивания больших кусков работы на key results/epics/features (ну или OKRs + features - в каждой компании такое называют по-разному). Я вообще большой нелюбитель распухших айтемов в таск-трекерах, потому что: • они бесконечны • не имеют целей и цифр, чтобы понять, когда нужно остановиться улучшать • не разделяют цели, обязательные для выполнения и дополнительные(я их называю stretch goals) Сама стараюсь бороться с этим следующим образом: 1. Все, что имеет видимость на уровне менеджмента+ максимально ограничивать по объему работы и закрывать, как можно быстрее. Все доделки забирать во внутренние процессы (работа с техдолгом, внутренние цели, и тд) Например, высокоприоритетные задачи по проблемам с продакшна нужно быстро раскидать, есть ли какой-то импакт для пользователей и если нет, настроить чувствительность алерта или полностью выключить его до выполнения long-term улучшения. 2. Эпики/фичи, за которые ответственна сама, всегда грумлю и пишу критерии выполнения разбивая их по обязательным и nice to have Примеры описания проблемы с цифрами: We need to redesign the OS image building pipeline to improve reliability, enable better traceability between images and platform code, and ensure compliance with security standards. This aims to reduce build failures, and provide CI validation for image-related changes, ultimately improving release stability and developer confidence. Data • 11% success rate for the past 180 days for the image building pipeline for DEV & TEST clusters (including retries) • 33% success rate for the past 180 days for the image building pipeline for PROD clusters (including retries) 3. Если есть какие-то метрики и цифры, то указывают минимальные границы выполнения Всем важен продакшн, поэтому завязываю критерии на него (на деве может падать и по куче других причин из-за догфудинга всех зависимостей сервисов Reliability • Success rate for image builds for SDP clusters improves to ≥70% (including retries). • Pipeline supports separate retry logic for Windows and Linux tasks. Validation • CI pipeline includes automated validation for image-related changes. • Validation failures block merges. 4. Сразу же создаю более мелкие таски, чтобы представлять объем работы и иметь возможность делегировать куски имплементации коллегам. В остальном ошибки - это часть работы инженеров и от них никуда не деться 🥲

Решила повайбкодить и вдохновиться одним из проектов, которые увидела в твиттере. С использованием github copilot CLI стало значительно сложнее следить за статусом сессий, поэтому захотелось завайбкодить TUI-based дашборд для отслеживания статусов. За полчаса был готов прототип. Пока пользовалась, нашла с десяток багов и недоработок, подпилила UI и теперь это вполне рабочая тула. В планах поиграться с уведомлениями и интеграцией с треем в макоси. Интересно узнать, а какие вы проекты делали для себя? 🤖

Красивый лендинг по поводу самоуправляемых кодовых баз https://background-agents.com/ У нас такого еще нет, но можно ассайнить таски на Copilota - он сам заберет всю информацию из таски, проанализует кодовую базу и сделает пулл реквест. Инженеру не нужно тратить свое время и внимание на постоянный мониторинг прогресса - только на код ревью. Отлично работает для простых или монотонных задач. С инфраструктурой есть нюансы - нужно хорошее покрытие тестами, чтобы автоматизация могла провалидировать все изменения и не было необходимости вручную что-то запускать или деплоить. Релевантная статья по имплементации от Spotify: https://engineering.atspotify.com/2025/11/spotifys-background-coding-agent-part-1

You know that I keep the most juicy articles for Friday, right? AI Isn't Replacing SREs. It's Deskilling Them. Here's the article. I leave you with that. #sre #culture

Я потихоньку начинаю замечать последствия AI-продуктивности. Теперь разработка останавливается, когда LLM перестает работать 🥲

Я очень активно пользуюсь Cline из-за его интеграции с VSCode LM API. Хочу отметить хорошее качество документации по всем фичам и стабильную работу самого расширения для VSCode. Наткнулась у них на таблицу сравнения разных провайдеров моделей - сама в основном использую Claud Opus 4.5 для планирования фичей/ресерча, Sonnet 4.5 для имплементации и Open AI GPT для общих вопросов/ресерча через chatgpt. Подробное сравнение моделей доступо здесь. Для повышения качества и консистентности результатов рекомендую использовать промт (наткнулась на него в одном из эпизодов подкаста Запуск Завтра).

🔒 Отключаем анонимный доступ к kube-apiserver, но оставляем health checks! Привет! Недавно ко мне пришел коллега-безопасник (Дима привет!) с интересным вопросом: как полностью отключить анонимный доступ к API-серверу Kubernetes, но оставить рабочими проверки /livez, /readyz и /healthz? 🤔 Сходу не ответил, полез копаться в исходниках и KEPах. Проблема в том, что по умолчанию (`--anonymous-auth=true`) любой может дернуть эндпоинты health-чеков и не только health-чеков: curl -k https://<API_SERVER_IP>:6443/livez # Output: ok Это удобно, но создает потенциальный вектор атаки, если RBAC настроен не идеально или найдется уязвимость. Безопасники такое не любят. 😟 К счастью, в KEP-4633 сообщество Kubernetes предложило решение! Теперь можно тонко настроить, к каким путям разрешен анонимный доступ, даже если глобально он выключен. Сделать это можно так: Сначала выключаем глобальный анонимный доступ в манифесте kube-apiserver: spec: containers: - command: - kube-apiserver # ... другие флаги ... - --anonymous-auth=false # <--- Выключаем! - --authentication-config=/etc/kubernetes/auth-config.yaml # <--- Указываем конфиг Затем создаем файл конфигурации /etc/kubernetes/auth-config.yaml на control plane нодах и монтируем его в под kube-apiserver: # /etc/kubernetes/auth-config.yaml apiVersion: apiserver.config.k8s.io/v1beta1 kind: AuthenticationConfiguration anonymous: enabled: true # Включаем анонимный доступ *только* для указанных путей conditions: - path: /livez - path: /readyz - path: /healthz *(Не забудьте добавить volume и volumeMount в манифест kube-apiserver для этого файла)* В итоге получаем: - Запросы к /livez, /readyz, /healthz проходят как system:anonymous. - Запросы к другим путям (например, /apis) без аутентификации получают 401 Unauthorized. Кстати, эта функциональность появилась как Alpha в Kubernetes 1.31 и стала Beta в 1.32. Теперь можно спать спокойнее, зная, что анонимный доступ под контролем! #kubernetes #k8s #security #authentication #kubeadm #devops #infosec

Недавно мне тоже нужно было делать ресерч на тему анонимного доступа к kube-apiserver. Если немного углубиться в тему, то можно найти ClusterRole под названием system:public-info-viewer. Она-то и управляет правами по умолчанию для группы system:unauthenticated, которая назначается всем запросам без аутентификации(помимо пользователя system:anonymous. При этом невалидные токены или сертификаты доступ к этой группе не получат. Поведение описанное выше валидно для vanilla-Kubernetes кластеров. Если вы используете flavored-Kubernetes, то конфигурация может отличаться. Сама роль выглядит довольно просто: ❯ k get clusterrole -n kube-system system:public-info-viewer -oyaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:public-info-viewer rules: - nonResourceURLs: - /healthz - /livez - /readyz - /version - /version/ verbs: - get Самым опасным из списка URLs кажется /version, так как он дает аттакующему информацию о текущей версии кластера(=версии kube-apiserver). Ну а по версии можно найти все неустраннеые уязвимости. Альтернативным способом уменьшения радиуса аттаки может служить патчинг ClusterRole, подробно описанный на gh.

dive Раз в 100 лет мне понадобилось поковыряться в образе, а dive стал как-то криво работать - одни образы распаковывает, другие нет. После изучения гитхаба выяснилось, что проект подзаброшен. Если вдруг кому-то тоже нужно, вот рабочий форк: https://github.com/joschi/dive. Запустить любой образ можно с помощью команды: dive python:3.11 # dive скачает образ, если его нет локально И потом можно в лучших традициях mc поисследовать файловую систему и как образ был собран.

CodingFont Game Забавный сайт для тех, кто никак не может найти идеальный шрифт для кода(у меня вышел Source Code Pro). Я уже много лет использую JetBrains Mono - дефолтный шрифт всех JB продуктов. Из интересных находок в прошлом году релизились семейство шрифтов от Github - monaspace. Но мне они особо не зашли 🤷‍♀️ Если у вас есть какие-то рекомендации, то велком в комментарии :)

Spegel Интересная имплементация stateless зеркала для OCI-реджистри, которая позволяет кешировать образы контейнеров в Kubernetes кластере. Помимо очевидных плюсов типа выживания во время даунтайма реджистри и мирроринга образов с публичных/общих внутри компании реджистри, будет полезно для ускорения старта подов с приложениями - особенно, если приложениям нужны тяжелые образа или часто происходят scale-up/down операции, ротация нод в кластере.

Давно хотела докинуть новых опций для gitconfig и наконец-то дошли руки. Чем вдохновлялась: - Блог-пост: Julia Evans: Popular git config options. Подробный разбор наиболее популярных опций по следам обсуждений на Mastodon. - Доклад со свежего FOSDEM 2024: So you think you know Git от создателя Github. Затрагиваются как старые, так и новые возможности. Для любителей энтерпрайза и монорепозиториев есть отдельная секция по оптимизации работы с ними. В довесок к CLI у меня еще есть пара стандартных расширений для VSCode: git history & git graph. Мой gitconfig можно посмотреть вот тут. Самая любимая команда - конечно же git squash N 🌚

#пятничное https://www.srenity.online/

How did I get here? Интерактивный сайт, на котором можно посмотреть какой путь проделывают пакеты с вашего компьютера до бекенда. Часть сайта генерируется налету, другая часть рассказывает про то, что происходит "под капотом" - traceroute, протокол WHOIS и немного про BGP. Выглядит интересно и в качестве пет-проекта 🤔 ps. по теме еще есть старый блог пост от Julia Evans - Tools to explore BGP