О, прям как по заказу подвезли! Не знаю как сейчас, но в первом издании Питера перевод был слегка корявым(не фатально)

Создание микросервисов

Сэм Ньюмен
2016

How we implemented RED and USE metrics for monitoring

Как устроен мониторинг в компании THRON.

https://medium.com/thron-tech/how-we-implemented-red-and-use-metrics-for-monitoring-9a7db29382af

#devops #monitoring
Щас может крамольную вещь скажу, но, имхо абсолютно не важно как собирать метрики и где их хранить. Все эти холивары а-ля графит vs пром и т.д. приносят больше вреда чем пользы, т.к. отвлекают от главного: важно не как собирать, а что собирать!
Обычно мониторят слоями, например железка-контейнер-оркестратор-прилажка. И если с первыми 3мя все понятно: вкрутил use/red/4gs и вперед, то что снимать с приложения, далеко не так очевидно. Конечно можно обвязаться теми же подходами, но боюсь, ваша идеальная утилизация/сатурация мало поможет бизнесу у которого клиенты не идут по happy flow. Конечно можно отдать это BIщикам, но, имхо, у них немного другая задача, да и вешать алерты на пентахо не очень удобно😁.
Кароч на подумать.

И еще один перевод на тему GitOps в нашем блоге — теперь уже подробнее о подходе в целом, его отличиях от Infrastructure as Code и Continuous Delivery: https://habr.com/ru/company/flant/blog/458878/

чет ору

Методичка как быть умненьким на любом митинге (работает во всех сферах):

https://www.sadanduseless.com/work-meeting-lifehacks/

и еще мемес, с которого ору вторые сутки(спасибо, Лентач)

Зарелизили наш меседж брокер на Кафке 2.0, теперь красивая версия Hermes 1.0.
(5 лет работы, но я последний год только).

https://allegro.tech/2019/05/hermes-1-0-released.html

#kafka
Вот еще поделие на кафке: https://github.com/zalando/nakadi и годный доклад по микросервисы впридачу: https://itnan.ru/post.php?c=1&p=322474

Lessons learned from running Kafka at Datadog

Полезные советы по Kafka от компании Datadog.

https://www.datadoghq.com/blog/kafka-at-datadog

How To Become a Data Engineer

A list of useful resources to help you learn Data Engineering from scratch

http://bit.ly/2G0H53V

К вопросу о мониторинге: братишки решили нод для кубера докупить т.к. в старые мощности уже шедуллер шедулить отказывался. Ну прикинули сколько машин надо, что по бабкам и почти уже согласовали, но тут кого-то черт дернул утилизацию имеющихся мощщей посмотреть. А там(барабанная дробь) по 30% от каждой виртуалки. Оказалось, что кто-то очень запасливый выставил подам реквесты с запасом в несколько раз и потом их забыли порезать
Мораль сей басни: инфраструктуру надо мониторить не только когда что-то сломалось, но и в динамике иногда поглядывать

Кстати, вот:

Практически все кто использует Kubernetes, рано или поздно, сталкиваются с необходимостью подсчёта потребляемых ресурсов. Следующая штука должна вам очень помочь https://github.com/rchakode/kube-opex-analytics/blob/master/README.md ну и вдогонку отличная статья на тему - https://medium.com/swlh/bringing-prometheus-metrics-and-grafana-dashboard-for-cost-allocation-on-kubernetes-clusters-1ee7f68cd677 #k8s #capacity

Terraform: Up & Running: Writing Infrastructure as Code, 2nd Edition (Early Release)

Yevgeniy Brikman

2019

Нашел вот такую: https://www.infoq.com/news/2019/06/risk-based-testing-agile/ штуку и она навела меня на мысль: возможно ли построить с риск-менеджментом что-то аналогичное обычным перфоманс-показателям(kpi)? Допустим, дядя в дорогом костюме лихо просчитывает риски на ближайшее будущее, принимает решения, что с ними делать(контролировать/минимизировать и т.д.), а потом эскалирует это все на мидл-менеджмент и бедалаги начинают рисовать свои паутинки рисков, конкретно по своим направлениям(тестирование, разработка, инфра и т.д.). Получается такой себе strategic vs tactic. Ну и в отличие от неработающих kpi и csf здесь хотя-бы можно будет будет порефлексировать почему риск сыграл, где его не учли и еще кучу полезностей
BTW царь-тестировщики подсказывают, что у них риск-бейзд тестинг уже давно изобретен. Ждем девРискОпс😂

#k8s
Как вам вот такая милота: https://azure.microsoft.com/mediahandler/files/resourcefiles/phippy-goes-to-the-zoo/Phippy%20Goes%20To%20The%20Zoo_MSFTonline.pdf ? Кубернетес для самых маленьких)

Внеплановый пост о том, что вчера я зарелизил Dephell -- инструмент для управления Python проектами с целой коллекцией фич: работа с зависимостями в любом формате, умный резолвер, аудит безопаности, поиск устаревших пакетов, просмотр лицензий зависимостей, управление виртуальными окружениями, бамп версии проекта, сборка пакетов, установка CLI инструментов в изолированное окружение и ещё много-много всего. Работал я над этим больше полугода, причем последние 2 месяца full-time, по 12 часов в день. Всё для вас ❤️

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

В то время, как эти ваши скрамы и канбаны придумали для продуктов, будущее которых не предопределено по умолчанию. Именно не предопределено, потому что вы знаете что пишете и зачем (т.е. для каких потребителей и решения каких проблем), но вы не знаете, чем станет ваш продукт через месяц, полгода, год.

Идея разбивать большой проект на много-много маленьких задачек появилась в следствие необходимости “доставлять” часто, но маленькими порциями в качестве откупа.

Эту идею подхватили мамкины стартапы, где инвестор заинтересован не сколько в продукте как таковом, а в том, чтобы увеличить стоимость продукта/стартапа максимально быстро (если быть точным - быстрее конкурентов, пока рыночек не порешал).

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

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

"Without requirements or design, programming is the art of adding bugs to an empty text file." (с) Louis Srygley