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

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. Говорят, почти не тормозит)

#yaml
Тут редхат подкинул 10 инсайтов для тех кого(как и меня) бесит ямл: https://m.habr.com/ru/company/redhatrussia/blog/462125/

Доклады с JPoint 2019 (лучшее)
https://www.youtube.com/playlist?list=PLVe-2wcL84b_fBL9xJTxkEBtvCKfRGEV1

Как вы, думаю, поняли по вчерашнему опросу, щас будет батхерт)
Вкратце история такая: коллега перестарался и оверинжинернул фичу. На ревью ему, конечно же, было на это указано и сказано создать задачу на доделку-переделку. Тут, внезапно, в вот это уже готовое потребовалось добавить еще свистелок-перделок. Естественно из-за царившего там ООП головного мозга ситуация вышла из под контроля. И вот меня, собственно, вызывают на ковер, с вопросом "че так долго?" Объясняю ситуацию, в ответ слышу "надо было сразу нормально делать, у вас жи для этого кодревью есть!". Не, хер возразишь, конечно...вот только у нас стартап и фича была на стадии проверки гипотезы, и, кмк, вкидывать туда еще N человеко-недель и заставлять делать щас и навека -- плохая идея, учитывая, что если функционал не зайдет, то выкинуть наколеночный прототип гораздо проще чем то что рожалось потом и кровью.
Так что, имхо правильный ответ "it depends". Если вы уверены, что то что вы делаете проживет долгие годы, то делать надо хорошо, а PoC надо делать быстро

Новый перевод на хабре — про chaos engineering (вы же слышали про chaos monkey? Вот об этих обезьянках в чуть более глобальном представлении): https://habr.com/ru/company/flant/blog/460367/

Что-то тут в очередной раз наткнулся, проорал, решил поделиться! Встречайте, игра образца 1972 года про paging! Рубрика "девелоперы шутят"

Новая статья от нашего инженера про миграцию в Kubernetes… на сей раз MongoDB, хотя подход аналогичен RabbitMQ:
https://habr.com/ru/company/flant/blog/461149/