I hate overtime

Самое (не-)приятное занятие в работе с людьми - объяснять и доказывать элементарные, на мой взгляд, вещи.

Список огромный, но самый излюбленный дискурс - High Availability (HA) против Disaster Recovery (DR). Люди, даже технически подкованные, часто путают или, что еще хуже, смешивают эти два понятия.

Есть простой пример "из жизни", который прекрасно дает понять контекст.
HA - это несколько двигателей у самолета.
DR - это что должно произойти, когда самолет падает или ударяется об землю.

Как _точно_ не делать микросервисную архитектуру. Надо быть самым настоящим космическим архитектором, чтобы это придумать.

TLDR: 200 calls * 99.9% uptime = 0% availability

Этот доклад вспомнился мне в одной беседе, удивлён, что я не постил его раньше.

https://www.youtube.com/watch?v=gfh-VCTwMw8

Пришел сегодня на проект, а там что бы логин работал... надо 3 микросервиса поднять.
Вечно можно смотреть на 3 вещи: огонь, вода и как Jimmy Bogard рофлит над distributed monolith

Ойой, ссылка-то потерялась: https://failover-conf.heysummit.com/

​​FailoverConf, 21 апреля, онлайн, участие бесплатное.

Бомбический список участников и докладов, регистрируемся!

В VictoriaMetrics появились алерты, которые они просят потестировать https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmalert

Хочется еще добавить к списку замечательный Code Podcast. Каждый выпуск(или серия) посвящены определенной теме общей для всей индустрии(например канкаренси, распределенные системы, фронтенд и т.д.). Но самое крутое в подкасте -- это гости! Там и создатель Idris и коммитер в Rust и куча других уважаемых людей. К сожалению, пока выпусков не очень много, но каждый прям решает.

З.ы. Подкаст англоязычный, но автор из России, т.о. все достаточно понятно.

Не опоздал, а дал возможность еще каналов довести.

@overtimehate - хороший технический блог
@rxd_txd - и еще один не хуже!
@numstation - научные штучки и мемы)
@count0_digest & @sysadmin_tools - 2 канала, без которых я не могу жить
@experimentalchill - непревзойденные канал Даниила о С++

@sysadminsu - админские полезняшки
@bpblog - сочные кастомные клавиатуры
@some_link_here - полезные и интересные айти ссылки
@meta_it - сборник айти-каналов (хотя большинство я вам озвучил)
@sec_devops - и сюда же secure devops, как же без безопасности в докере?
@dereference_pointer_there - если интересен Rust и о его непопулярных вещах.

@software_engineering_blogs - лента постов от известных фирм, чем-то напоминает HN comments @hn_best_comments (от @korkoma)
@isast - анализ и сертификация безопасности приложений в промышленных масштабах
@golangquiz & @quizcpp - если хотите потестить свои скилы в Go и С++
@alexandersmind - личный айти бложек
@smmblog - на стыке IT и предпринимательства, продуктовая, предпринимательская сторона работы.
@pdp11ml - Domain Specific Computing for machine learning (хотя там кроме МЛ есть вещи)
@coderoll - о веб-разработке

@qtasep - о жизни и непонятной математике
@lowlyingscience - science 👌
@microservices_arch — канал называется микросервисы, но целом по архитектуре.
@dddevotion — канал про ДДД
@pathetic_low_freq - известные, но "жалкие" низкочастотники

Давайте, репостите!

Тут по каналам волна рассказов про подкасты прошла и я тоже решил поделиться.

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

1. "Цинковый прод" (@ZnProd).

Подкаст строго 18+, слушаю его с самого первого выпуска и всегда радует. Он, в каком-то смысле, антипод "прилизанного" "Радио-Т" и это только в плюс.
Подкаст про обсуждение новостей, технологий, в обязательном порядке Rust'а (локальный мемас). Из последнего, что зацепило и было наиболее интересно это выпуск про использование Rust в бэке продукта для бирж https://soundcloud.com/znprod/054-15k-rps-z-1-ms.

2. "Generic Talks" (@generictalks)

Этот подкаст тоже слушаю с первого выпуска. Одним из ведущих является автор канала @oleg_log. Достаточно хардкорный подкаст с рассказами про кишочки с упором в Go, но и не только в него. Ярким примером этого является выпуск про обновления в Go 1.14 - https://t.me/generictalks/57.

3. Geek Export (@geekexport)

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

Наиболее близкие выпуск к тематике моего канала, я думаю, это №5
Берлинский стартап хаб и DevOps
https://soundcloud.com/geekexport/5-berlin-devops

---

Если вы хотите поделиться каким-то мнением по подкастам, поделиться подкастом чужим/своим, то пишите в личку. С удовольствием пообщаюсь.

Рассказ «Одноклассников» про их кластер Elasticsearch. Какие проблемы были, как решали и как жить с этим добром.

Кластер Elasticsearch на 200 ТБ+
https://habr.com/ru/company/odnoklassniki/blog/494260/

Новая статья от Флант, на этот раз про ресурсы в Kubernetes
https://habr.com/ru/company/flant/blog/489668/

#dotnet #sre
Кстати про сервисы, тут Jimmy Bogard начал цикл статей про distributed tracing вообще и в .net в частности. Если планируете вкручивать, то рекомендую ознакомиться(квест тот еще, т.к. Opencensus уже забросили, а OpenTelemetry еще не сделали)

service size twitter см:https://t.me/oleg_log/3017

Немного запоздалых новостей:

- На GitHub появилась коллекция JavaScript State Management Tools, в которой на первом месте Effector
- GitHub наконец-то одобрил добавление топика effector
- Я сделал шаблон Effector SSR, для быстрого старта разработки на TypeScript, React, Effector, Razzle, StyledComponents
- Часто вижу вопросы, как сделать debounce на Effector, и поэтому сделал библиотеку для этого 👀. Вообще, это больше в качестве примера написания библиотек для эффектора. В репозитории есть тесты на сам debounce, а также на корректность работы в fork.
- Я продолжаю писать генератор кода из Swagger/OpenAPI в ActixWeb

тема про "почему" оказалась достаточно интересной ;) https://www.oreilly.com/radar/the-infinite-hows/

Спасибо читателям - подсказали что семь "почему" лучше пяти :) https://www.emofree.com/npno/articles-ideas/core-issue/seven-whys-article.html

#meatware
Если у вас есть четкое ощущение, что вы часто боритесь не с причинами, а с следствиями, то вот вам отличный метод как докопаться до root cause.
Метод заключается в последовательном задании вопроса "почему?" 5 раз))) Давайте включим Игоря Николаева и попробуем найти 5 причин:
- Мой софт упал
- Почему?(1)
- Потому что сервис А вызвал В, а тот не отвечает. Произошел каскадный отказ
- Почему?(2)
- Потому что не подумали о fallback
- Почему?(3)
- Потому что нет политики design for failure
- Почему?(4)
- Потому что у команды нет экспертизы
- Почему у нас тогда распределенная архитектура?(5)

З.Ы. Как сообщают эксперты, главное избегать ответов в стиле "потому что Х мудак!" и "потому что иди на х$й, вот почему!"