Пятничный деплой
4.46K subscribers
1.41K photos
29 videos
167 files
7.78K links
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://xn--r1a.website/s/count0_digest
Download Telegram
Forwarded from linkmeup
Я обычно не люблю, когда программисты вещают про сети, но тут прям хорошо. Без заумных слов и чтобы понял даже самый отбитый девопс. Мне кажется, это верный признак того, что автору пришлось усиленно разбираться в теме, перед тем как делать и выходить на публику.
Даже от набросов сетевиков в конце отбился достойно.
https://www.youtube.com/watch?v=-6iWRYkeF14
👎5👍4
Товарищи настраивали web application firewall․ Прислали им новый список айпишников‚ которые надо добавить в whitelist․
Полетел список по процедуре к инженерам‚ те копипастнули и фиганули на прод.
Конечно, всё упало․
А почему упало
Потому что в условно 5 из 200 айпишниках вместо обычной точки использовалась армянская точка․

Будьте внимательнее‚ когда получаете данные! Ну нельзя же спутать

127։0։0։1
127·0·0·1
127․0․0․1

Правда

Вам кажется‚ что вы никогда не попадёте в такую ситуацию
Тогда обратите внимание‚ что в этом тексте нет НИ ОДНОГО стандартного знака препинания!
‚ ‒ это не ,
․ ‒ это не .
и даже вот чёрточки ‒ которые использовались выше - это не дефисы, и даже не тире․
👍3👎2🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Дорогие программисты (особенно кто кодит не профессионально и не часто), если не пользовались Cursor — рекомендую попробовать.

Это редактор кода на основе VS Code, в который встроили хорошую поддержку AI. Можно выбирать API из множества провайдеров, он сам корректно добавляет контекст, очень удобно подсвечивает добавления/изменения кода.

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

Лично для меня полезно, потому что я программирую редко и часто не помню интерфейсы библиотек (и даже части синтаксиса), но хорошо понимаю, что хочу получить.

Хорошие фул-тайм программисты говорят, что им полезно как мощный инструмент рефакторинга, который берет на себя рутину.

Я сижу на бесплатном тарифе, больше тяжелых запросов — за 20$ в месяц.

Upd. Коллеги напоминают, что совсем недавно Lex Fridman взял интервью у создателей — занимательный разговор!
👎12👍1
Forwarded from Enabling.team Insights
В конце октября 2024 года вышел 10-й юбилейный отчет Accelerate State of DevOps 2024 от DORA и Google Cloud. Напомним, что исследование Accelerate State of DevOps проводится ежегодно с 2014 года, за 10 лет в исследовании приняли участие свыше 39 тысяч профессионалов по всему миру, работающих в компаниях различных размеров и отраслей. Авторы отчета - команда DORA (DevOps Research and Assessment), которая входит в Google Cloud и состоит из исследователей, архитекторов, консультантов, технических писателей, экспертов по UX и DX. В этом году отчет получился на 120 страниц, мы внимательно изучили новый отчет и подготовили краткий обзор.

Исследование в этом году сфокусировано на таких направлениях и практиках, как применение AI, Platform Engineering, Developer Experience, Transformational leadership и их влиянии на Software delivery performance, Reliability, Product performance, Team и Organizational performance, Productivity и Well-being.

Что интересного мы отметили:
1. В исследовании приняло участие 3000 профессионалов из 3-х основных индустрий Technology (36%), Financial Services (16%) и Retail/E-commerce (9%). Большинство участников (76%) работают в компаниях размером больше 100 сотрудников, 46% в компаниях больше 1000 сотрудников. Инженеров и руководителей практически поровну, 90% FTE (Full-time employee), в среднем имеют 16 лет опыта, 5 лет на текущей роли и 3 года в текущей команде. Участники исследования из 104 стран, топ-6 стран: США, Великобритания, Канада, Германия, Япония, Индия, есть участники из Китая и России;
2. В начале отчета даны хорошие определения ключевым терминам, практикам и метрикам используемым в исследовании, чтобы синхронизировать терминологию;
3. По изменениям в ключевых метриках: в прошлом году Time to Restore Service переименовали в Failed deployment recovery time, в этом - Change failure rate переименовали в Change fail rate и экспериментируют с 5-й метрикой Rework rate, а также изменили концепцию измерения Software Delivery Performance;
4. По изменениям в профилях эффективности команд: соотношение Elite (19%) и Medium (35%) осталось практически без изменений с прошлого года, профиль High сократился на 10%, а Low вырос с 17% до 25%;
5. По изменениям ключевых метрик в профилях: Change fail rate у профилей High вырос с 10% до 20%, у Medium сократился с 15% до 10%, у Low сократился c 64% до 40%. Также у Low профилей Deployment frequency и Change lead time увеличился до 6 месяцев;
6. Приведены результаты исследования применение AI практик и инструментов и их влияние на ключевые метрики, индивидуальную продуктивность и инженерные практики. Этому направлению отведено четверть отчета, отметим хорошо составленный набор задач для которых применяют AI инструменты и анализ доверия к результатам работы AI инструментов;
7. Отдельная секция посвещена Platform Engineering, авторы ссылаются на книгу Team Topologies, опыт компаний Spotify и Netflix, дают хорошее определение: "Platform engineering is a sociotechnical discipline where engineers focus on the intersection of social interactions between different teams and the technical aspects of automation, self-service, and repeatability of processes". Исследуют влияние внутренних платформ (Internal developer platform) на индивидуальную и командную продуктивность, на ключевые метрики и результаты в разрезе 1, 2 и 5 лет использования платформ;
8. Исследование затронуло применение продуктового подхода (User-centered approach) в командах, в отчете приведены результаты влияния на Developer Experience и ключевые метрики;
9. Из Transformational Leadership охвачены такие аспекты как: Vision, Inspirational communication, Intellectual stimulation, Supportive leadership, Personal recognition и их влияние на Employee burnout, Job satisfaction, Team performance и Organizational performance;

В конце отчета рассмотрена методология, включающая модель исследования, форматы проведения интервью и опросов, примеры гипотез и вопросов, исследуемые инженерные практики, метрики и результаты. Подробнее про результаты исследования читайте в новом отчете Accelerate State of DevOps 2024.
👍21
🔩 Boot Time Presentations - сборник докладов и выступлений, тема которых так или иначе связана с ускорением загрузки системы.

Материалы представлены в списке от самых свежих - выступлений 2024 года, до самых старых - презентаций 2006 года...

https://elinux.org/Boot_Time_Presentations

#linux #boot #speed
👍3
Forwarded from DevOps&SRE Library
Understanding DNS in Kubernetes

In this post, we will cover the following:

- Overview of DNS Resolution and CoreDNS, the default DNS provider in Kubernetes.
- Kubernetes DNS policies, such as ClusterFirst, Default, and None, and their effects on pod DNS configurations.
- Differences between The GNU C Library (glibc) and musl libraries.


https://povilasv.me/understanding-dns-in-kubernetes
Forwarded from PythonDigest
Mount — ещё один способ уменьшения размера Docker-образа
https://ift.tt/i30KPnG

Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby... Обновили Ruby-пакеты и под них код, написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб. Cделали следующее, чтобы сократить размер
👍7👎4
Forwarded from PythonDigest
Werkzeug - 3.1.2
https://ift.tt/63TjigP

Швейцарский армейский нож веб-разработки Python. Скачать можно по ссылке: https://pypi.python.org/pypi/Werkzeug/
🔥1
Forwarded from linkmeup
Собственно, тут как в анекдоте - два путя.
Первый: ты в курсе, что DNS это не только чОрная магия, но ещё и увлекательный тулинг вокруг, поэтому ржёшь над девопсами, узнавшими про NS1.
Второй: ты никогда не слышал про NS1, route 53 и прочие DNS-сервисы, поэтому в докладе тебя ждёт удивительный мир.

https://www.youtube.com/watch?v=Fa2-CdzY75g
👍5🔥2
Forwarded from PythonDigest
PSQLBuddy — резервное копирование и восстановление PostgreSQL
https://ift.tt/pic3CIe

Все мы так или иначе решаем вопросы резервирования наших данных. Но всегда хочется, чтобы думать об этом приходилось как можно меньше, стоило это дешевле, а восстановление было простой задачей. Это я и попытался сделать в своем проекте PSQLBuddy.
Как-то я пропустил, но тут в сентябре наконец-то выпустили Falco Talon условно стабильной версии.

Falco, если кратко, мониторит системные вызовы, анализирует что происходит и выдаёт предупреждение, если что-то нарушает его правила (делает это не только для Kubernetes, но и хоста).

Раньше, после того как Falco стриггерился на что-то, надо было придумать как на алерт реагировать. Так же Falco не позволял выстроить цепочку событий, которая бы объясняла, как к событию в алерте пришли.

Например, об этом рассказывал @gecube тут
https://youtu.be/uKX8TaLJK6E?t=293

Ответом на запрос в контексте реагирования появился Falco Talon
Falco Talon is a Response Engine for managing threats in Kubernetes clusters. It enhances the solutions proposed by the Falco community with a no-code tailor-made solution. With easy rules, you can react to events from Falco in milliseconds.

Introducing Falco Talon v0.1.0
https://falco.org/blog/falco-talon-v0-1-0/

Если кратко, то как это работает (схематично на первой картинке)

Falco ловит событие, которое прокидывается на falco-talon (можно через sidekick). После этого, согласно настроенным actionner выполняется действие. На данный момент список поддерживаемый
- kubernetes:terminate
- kubernetes:label
- kubernetes:networkpolicy
- kubernetes:exec
- kubernetes:script
- kubernetes:log
- kubernetes:delete
- kubernetes:drain
- kubernetes:download
- kubernetes:tcpdump
- aws:lambda
- calico:networkpolicy
- cilium:networkpolicy

https://docs.falco-talon.org/docs/actionners/list/

Как это можно применять можно почитать в посте от Sysdig
Optimizing Wireshark in Kubernetes
https://sysdig.com/blog/optimizing-wireshark-in-kubernetes/

Там они рассказали, как дампили трафик с помощью Wireshark, отправляли в Falco, а потом с помощью Falco Talon реагировали на то что происходит.

В посте, где рассказывают про релиз, показан пример со складированием трафика в Amazon S3 (на второй картинке)

GitHub
https://github.com/falcosecurity/falco-talon

Документация
https://docs.falco-talon.org/
🔥31👍1
Аналогичная штука для командной строки — Warp. Терминал с нормальной поддержкой AI.

Одну из ключевых идей Юникс можно понять за минуту: каждая программа должна уметь делать только одну вещь и делать её хорошо. Программы можно комбинировать, передавая результат работы первой как входные данные для второй, создавая сколь угодно длинные цепочки.

По сути, ты получаешь в руки набор кубиков Lego и каждый раз собираешь именно ту программу, которую нужна тебе прямо сейчас. Безграничные возможности.

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

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

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

Последние годы я часто обнаруживаю себя в ситуации, когда знаю, что задачу можно решить с помощью Шела за пару минут, но трачу полчаса на поиск нужных команд и ключей.

Warp возвращает мне эти знания, а порой подсказывает вещи, которых и я не знал никогда.



На практике, вместо написания команд можно нажать шорткат и сказать, что хочешь получить — на английском — и Warp предлагает тебе команду.

При этом у него есть контекст происходящего — что ты делал раньше и каким был результат. Можно прямо сказать «там че-то homebrew ругается, почини». И он чинит!

А ещё у него обычный ввод текста, не readline, так что можно наконец редактировать длинные многострочные команды прямо в нем.

Я сижу на бесплатном тарифе — 100 AI-запросов в месяц, дальше от 15$ в месяц. Пока только для Mac и Linux, Windows версию обещают скоро.
👎15👍6
Forwarded from DevOps Deflope News
Долгожданный релиз containerd 2.0 предлагает множество новых функций, включая поддержку плагинов для проверки образов и интеграцию с OpenTelemetry. Это первое мажорное обновление с 2017 года.
🔥15
Forwarded from Go Library
Writing a circuit breaker in Go

https://rednafi.com/go/circuit_breaker
👎1
Forwarded from DevOps FM
👩‍💻 В каких случаях может понадобиться создать образ Docker без использования Dockerfile? Когда нужно, чтобы слои образа создавались параллельно, вся обработка выполнялась в памяти без обращения к файловой системе, а ещё была возможность использовать собственные правила кэширования данных.

В своем блоге Адольфо поделился опытом работы с dockerfileless-образами контейнеров. Два главных урока, которые вы можете вынести из статьи:

1. It is a true pain to deal with OCI images manually.

2. Рeeking under the hood of container images will not void your warranty, and is a great way to get a better idea of what an OCI image actually is.


#devops #docker #контейнеры
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥4
Forwarded from DevOpsConf Channel
Ops или Engineering?

Новый, с пылу, с жару выпуск подкаста с Игорем Курочкиным — членом Программного комитета DevOpsConf 2025. Обсуждали DevOps и развитие инжиниринговых практик.

Говорили бодро, также обсуждали NextOps, который не то, чем кажется! Вспомнили массу приятных книг и не только.

Слушайте 321 подкаст The Art of Programming 🔄

iTunes
ВКонтакте
Яндекс Музыка

🖐️ CFP на DevOpsConf 2025 открыт

П.С. Cut-Cut 321. Ops или Engineering? тут.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1👎1
Forwarded from DevOps Deflope News
Вышел Jaeger v2. Новая версия интегрирует OpenTelemetry и предлагает пользователям улучшенные возможности обработки данных и упрощённое развёртывание: https://goo.su/GuMQln
👍2
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async. Часть 11. Сравнение видов многозадачности

В прошлом посте было дано определение 2м основным видам многозадачности используемых в Computer Science. В этом посте хочется дать чуть больше пояснений и порассуждать где и почему они применяются.

Вытесняющая многозадачность реализована на уровне ОС, практически все системы которые я знаю реализуют подход с вытесняющей многозадачностью. Этот подход позволяет пользователю ощущать что все запущенные программы на компьютере работают параллельно (при наличии ядер процесссора, помним про SMP). А если не параллельно то как минимум конкуррентно, то есть каждой задаче выделяется ресурс "поработать" а дальше ОС останавлвает программу чтобы выделить ресурсы соседнему процессу.

Какие основные плюсы и минусы есть у данного подхода к мультизадачности:
- Плюс: невозможна ситуация когда ресуры системы голодают (starvation) в ожидании работы. Планировщик всегда найдет для процесса поток и ядро процессора для исполнения команд.
- Минус: наличие планировщика так или иначе дает оверхед.

Если переходить к кооперативности то тут основной плюс в том что переключениями может управлять разработчик (Ну или рантайм языка программирования, т.е нечто на уровне самой программы а не ядра ОС). И планировщика может и не быть вовсе. Но имея такую силу в своих руках можно получить ситуацию когда мы пишем кооперативный код который с легкостью заблокирует всю программу и не передаст возможность делать полезную работу дргим файберам в рамках процесса. По сути программа зависнет и придется ее перезапускать. Чуть менее критичная ситуация - starvation, когда файбер не передает ресурсы другим файберам хотя ему они сейчас не нужны (например он заблокировался на IO).

Так зачем вообще нужно использовать кооперативную многозадачность? Давайте использовать нативные треды операционной системы и не будем париться? За нас все сделает ОС. Такой подход вполне имеет право на жизнь, но он является достаточно дорогим с точки зрения ресурсов. Треды дороже с точки зрения памяти + ими управляет ОС и переключения между ними очень дорогие. При этом помним что при разработке серверных программ большое количество времени программа проводит в состоянии ожидания ввода-вывода и для эффективной утилизации ресурсов и комфортного пользовательского опыта важно чтобы во время простоя могли выполняться другие задачи на железе.

Для того чтобы программисты могли писать IO bound программы эффективнее разработчики языков и начали привносить в рантаймы различные легковесные примитивы. Но что произойдет в программе если мы сделаем блокирующий вызов (например запрос к БД)? Зависит от того как реализован рантайм конкретного языка программирования. Где то мы в ответ получаем Promise и продолжаем выполнение программы и заблочиться на нем в ожиданиии результата спустя время. В других языках реализованы специальные планировщики которые умеют детектировать файберы которые заблочились на IO и их можно безопасно снять с реального потока ОС и выделить время другим файберам. То есть по сути получаем некоторый микс из двух подходов, взяли лучшее из каждого.

А как быть с CPU Bound задачами? Никак, CPU задачи не масштабируются с помощью файберов. Чтобы разобраться почему приглашаю читать предыдущие посты с обсуждением процессора😊

На этом на сегодня всё, спасибо что читали, до встречи в следующих постах.😇
Forwarded from Go Library
Fuzz Testing Go HTTP Services

As a developer, you can't envision all of the possible inputs your programs or functions could receive. Even though you can define the major edge cases, you still can't predict how your program will behave in the case of some weird unexpected input. In other words, you can only find bugs you expect to find.

That's where fuzz testing or fuzzing comes to the rescue.


https://packagemain.tech/p/fuzzing-http-services-golang