Митап с окрошкой и инцидентами

10 августа в нашем офисе пройдет четвертый митап в серии Backend United, который получил название «Окрошка».

В программе — доклады про инструменты для улучшения incident response, работу с продакшн взрывами, ценность технического долга, автоматизированный сбор сведений при значительных инцидента. А во время перерыва запланировали поедание окрошки.

Если вам всё это интересно, то регистрируйтесь на встречу на таймпаде. Подробнее о докладах можно прочитать на Хабре.

Почему-то потерялась ссылка на хабр Выглядит интересно, #ябсходил

В тему инцидент менеджмента. Как-то зацепились с Пашей из ОкМетра языками за anomaly detection в мониторинге. Его поинт был: anomaly detection as a service -- маркетинговый булшит и ничего более, я же апеллировал к тому, что у "конкурентов"-то(datadog, appInsides и т.п ) он цветет и пахнет и, самое главное, продается. Тут Паша высказал мысль от которой у меня чет прям очень мировозрение пошатнулось: если мы не верим, что это будет работать и приносить клиенту value, а считаем что это просто маркетинговый булшит, то делать мы это не будем.
Сцуко, а что, так можно было?! На подумать кароч)

Большая стать от DataDog об уроках использования Kafka

В статье описывают:
- пути безболезненного изменения максимального размера сообщения
- unclean leader election: плюсы, минусы, подводные камни
- конфигурацию retention period для топиков с низкой частотой записи и на что стоит обращать внимание + настройку retention для такого типа топиков

Кроме того, DataDog заопернсорсили свой Kafka-kit - набор утилит понятно для чего. Ну и статейка про эти утилиты

#kafka

Перевели postmortem от Grafana Labs про их недавний фейл с Kubernetes: https://habr.com/ru/company/flant/blog/461807/

Тут лухари-ретроспектива эволюции Slack'а подъехала. Со времен основания и до наших дней. Наслаждайтесь)
З.Ы. особенно круто, то что из наколеночного стартапа где никто особо не шарил они смогли вырасти и не загнуться. Под катом много инсайтов как смочь быстро и качественно

Задачи на собеседование

Недавно мне попалась на глаза задача на вакансию linux-администратора в одну известную компанию. Вопрос звучит следующим образом:

Вам нужно проапгрейдить ядро и операционную систему на ста одинаково настроенных серверах. Как вы будете решать эту задачу?

Вопрос никоим образом не сложный, но позволяет сразу прочувствовать знания соискателя. Прежде чем высказать свое ИМХО по этому вопросу, я запущу опрос и дам вам время чтобы вы могли составить собственное мнение.

А теперь немного моего ИМХО по этому поводу.
Существует несколько нюансов при выполнении этой задачи.

1) Никогда нельзя быть твердо уверенным что обновление сервера, с уставновленными из репозитория пакетами пройдет без сучка и задоринки, поэтому нельзя быть уверенным, что если мы запустим ансибл по 100 серверам у нас вообще все это выживет. Бывали случаи когда какие-то пакеты конфликтовали, и новый дистр не поднимался успешно. Ну и наконец где ваша уверенность что софт, установленный из репозитория текущего дистрибутива есть в новом??? Таким образом 2,3 варианты ответов отметаем сразу.

2) как сказано в условиях задачи "одинаково настроенные". На самом деле нет. Это в идеальном мире можно условно "расклонировать" 100 раз службу и получить одинаковый результат. По факту всегда найдется какой-то "любимый" некоторым сисадмином сервер, на который тот ходит руками. Не важно зачем - логи читать или статус софта запрашивать. А еще бывает иногда необходимость выкатить условно-релизную версию софта на сервер, чтобы убедиться, что релиз не положит весь поток продового трафика. И вот уже у нас вроде бы 100 одинаковых серверов, а вот уже и нет, даже если потом все сервера приводятся к одинаковой версии софта.

3) самое важное - это как раз необходимость изучить, какую же вообще выполняют задачу эти 100 серверов.
3.1) У нас 100 серверов-воркеров. на сервере крутится служба, которая ходит в очередь и выполняет задание. При простое одного такого воркера вообще никто не заплачет. Можно выдергивать и обновлять.
3.2) У нас кластер на 100 машин. Например куб. или эластик. Опа, а вот тут уже начинаются первые вопросы. Если мы обновим дистрибутив, сможет ли вообще наше приложение существовать в новом окружении? не посыпется по зависямостям? ничего лишнего не снесется? Все ли нужные пакеты запинены? не приведет ли новое ядро к тому что будет падать в корку приложение? Что вообще произойдет с подами куба если мы выведем ноду из обслуживания? А вдруг у нас настроено афинити и приложение жестко привязано к этой ноде и когда мы ее положим оно нигде не поднимется? С базами тоже интересно, нужно знать, достаточно ли у нас реплик, что шардинг разнесен правильно. В случае с тем же эластиком, например пишется такой плейбук, который дожидается пока не поднимется предыдущий сервер, прежде чем обновлять следующий.

Поэтому такие задачи требуют глубокого изучения, построения сценариев обновления, написания автоматизации, а возможно подъема различных стендов, на которых все это будет обкатываться. А уж какой командой мы обновлять будем сервер и ядро - это никому не интересно.. 😃

Подьехала тут пачка инсайтов от Нетфликса про инцидент менеджмент и как расти через инциденты. Я чет прямо орнул с working with people in this context can be the “hardest problem in tech”. Кажется, это можно смело распространить на все IT😂

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

Кстати, сегодня торжественно снесли https://www.weave.works/docs/scope/latest/introducing/ т.к. воспользовались ровно один раз за пол-года(когда надо было инвесторам красивые картинки показать). Для картинок удобно, практической пользы меньше нуля(т.к. жрет больше чем пол-ядра)

Выбираем ingress для kubernetes https://itnext.io/kubernetes-ingress-controllers-how-to-choose-the-right-one-part-1-41d3554978d2 #k8s #ingress

#nodejs #async
Немножко nodejs вам в ленту!
Еще одна годная статья про то какую проблему в свое время решила нода(да и в целом V8), куча примеров и смищных картинок!

И даже такое есть в наших интернетах:
Paxos Jokes - Geeking out about distributed systems

Leader - I tell you Paxos joke, if you accept me as leader.
Quorum - Ok comrade.

Leader - Here is joke! (*Transmits joke*)
Quorum - Oookay...

Leader - (*Laughs* hahaha). Now you laugh!!
Quorum - Hahaha, hahaha.

http://paxosjokes.com/#!/

Кстати, вот картинка смешная, а ситуация страшная. Очень часто сталкивался с удивлением в глазах у людей, когда на их утверждение "да это же блокер!" спрашиваешь "а, собственно, почему?". Дальше имеется 2 варианта развития событий: либо достается табличка/чарт с критериями приоритезации багла, с нее сдувается пыль и баг сверяется с этим делом, либо же человек заявляет что-то типа "я художник, я так вижу!"
В обоих вариантах, как не странно, есть свои плюсы! И если в первом случае они очевидны, то в кругу "художников" рекомендую делать так:
1. берете поп-корн и пиво
2. зовете другого "художника" с противоположной позицией по вопросу
3. стравливаете эту парочку между собой
4. Включаете pixies
5. Открываете поп-корн

Автор Joy of Haskell сделал список алг. структур.

Вместо тысячи причин:
I keep forgetting what the difference is between a ring and a group, which is funny to me because I never forget the difference between a semiring and a semigroup

https://argumatronic.com/posts/2019-06-21-algebra-cheatsheet.html

#kafka #eda
Тут открыл для себя книженцию. Весьма полезно если вкручиваете каффку(дада, греффневую) Прям рекомендую

А вот тут дядя заморочился и собрал список ссылок и матриалов из книжки: https://gist.github.com/giampaolotrapasso/71221f378770e21e6270ffed76b181d7

Лонгрид для выходного дня о распределенном трейсинге от Cindy Sridharan.

В статье описано, какие возникают проблемы при построении трейсинга и как их можно принципиально решать.

#observability

Spyware на java: https://github.com/tiagorlampert/sAINT. Говорят, почти не тормозит)