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 из В) и тикет летит через забор. Но тут ребята категорично ответили, что ничего не меняли и ваще "сами мейнтейньте" и кинули обратно. Такой себе джира пинг-понг.
Мораль... если не умеешь в распределенные архитектуры, то может и не надо? А вот за Кодда обидно, конечно

#monitoring
Тут недавно произошла интересная история. Модно-молодежно собирая метрики в пром и прикрутив к нему графану и алертинг мы стали спокойно спать по ночам. Помимо традиционных алертов на ресурсы, кубер и каких-то бизнесовых показателей мы везде поставили алерты на отсутствие данных(сервис помер и ничего не отправляет). И вот в один прекрасный день в слак прилетает пачка зеленых алертов из категории "все пропало". Сразу зеленых, красных не было. Пошли разбираться: оказывается кубер решил перезагрузить прометеус и графана на несколько минут потеряла связь с промом что и вызвало недопонимание с ее стороны. Но! Так как алерты на отсутствие данных у нас были, а вот алертов на недоступность data source не было, то о падении мы узнали только пост-фактум.
История смешная, а ситуация страшная: если бы в этот момент свалился еще и прод или вырубился бы весь куб-кластер, то об этом бы мы узнали только от пользователей.
Кароч выводы мы сделали такие: алерты надо тестировать. Причем, перед этим, надо тщательно продумать и приоритезировать все кейсы. Ну и вот парочка крутых видосов про мониторинг\алертинг от Контура: раз два

#k8s
И альтернатива: https://github.com/kubecost/cost-model

Еще большой список cheatsheets: https://devhints.io/

Ну и куда же без пятничных мемесов

Смотрите видео с выступления Сергея Долганова на #ДАМП с докладом про то, как типы и функциональный подход могут вдохнуть новую жизнь в создание контрактов для API:

https://www.youtube.com/watch?v=x_vN2a1BldY