чет ору

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

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

#microservices
Подъехал лонгрид про антипатерны микросервисов от гуру: https://microservices.io/microservices/antipatterns/-/the/series/2019/06/18/microservices-adoption-antipatterns.html как удачно, все шишки в одном месте)

Linux уверенно завоёвывает позиции основной ОС для баз данных. Это понятно, так как open source баз данных всё больше. Но есть одна проблема — производительность IO. Хорошо, что в Linux последние годы идет капитальный ремонт IO-стека и есть надежда на просветление.

Подробности — в расшифровке доклада Ильи Космодемьянского (Data Egret) на HighLoad++ 2018.

#devops #database
С IO действительно очень много проблем и очень сложно продраться через огромную кучу абстракций. Очень радует, что сейчас начали что-то делать с IO-стеком и есть подвижки. На счет баз, из моего(скудного) опыта, хочется посоветывать выбрать нормальную FS(ваш кэп). Лишние журналы, люто жрущие диск, не очень помогают базенке.

#k8s
Очередной набор cheat-sheetов подъехал, на этот раз от RedHat

Что-то очень орнул сегодня:
Две команды разрабатывает 2 "микросервиса". По лучшим традициям, сервисы связаны максимально жестко: практически на каждый call сервиса А идет запрос данных из сервиса В и наоборот. И вот в одном из сервисов, допустим В, парни придумали хранить несколько типов сущностей в одной скуль-таблице(Кодд, прости, мы все про...), но, со временем все же исправились и решили нормализовать. Вот только к таблице была прикреплена APIшка для сервиса А, которая теперь гордо возвращает 404 для большей половины запросов.
Дальше больше: дефект заметила команда сервиса В, которая добропорядочно отрепортила его в А а-ля чет у вас там пятисотит. После недолгого инвестигейта находится источник(404 из В) и тикет летит через забор. Но тут ребята категорично ответили, что ничего не меняли и ваще "сами мейнтейньте" и кинули обратно. Такой себе джира пинг-понг.
Мораль... если не умеешь в распределенные архитектуры, то может и не надо? А вот за Кодда обидно, конечно