ELK + syslog http://devconnected.com/monitoring-linux-logs-with-kibana-and-rsyslog/ #elk #syslog

И третья точка зрения на девОпс(и все разные)! Коллекция растет)

Не пользы ради, а флейма для

Хм, я всегда считал, что девопсы это такие ж разрабы(омг), просто дальше от фич приложения и пользователей(поэтому больше скилов администва, ведь работаю около инфры).

А пихать все в одну должность - прост грузить сотрудников.
(Комбо с названием канала отлично доставляет)

Конечно все зависит от размера фирмы и навыков разрабов. Хотя и тут можно много мегабайт текста наспорить.

https://news.1rj.ru/str/overtimehate/489
(Там след пост - инициатор темы)

(Если скучно - можете мне в свои отношение высказать-выплакать @olegkovalov)

#coroutines #java
Еще один крутой видос про асинхронщину и детерменизм, на этот раз в java: https://youtu.be/9vupFNsND6o

k14s — тулсет для работы с Kubernetes от Pivotal (нейминг от бога)

Включает в себя:
- ytt — утилиту для YAML темлпейтов
- kbld — утилиту для сборки образов
- kapp — утилиту для деплоя приложений

+ в статье есть пример с хеллоуворлдом

#kubernetes

#k8s
Еще одна деплой-тулза для k8s. Интересна тем, что в отличие от хельма умеет не сносить приложения которых нет в "umbrella-чарте"(только обновлять указанные). Для хельма нам пришлось для этого навернуть целую систему костылей. И еще это не один большой комбайн, а набор single purpose утилит. Кароч я бы присмотрелся.

Production readiness

Советы от инженера Google Cloud на что стоит обратить внимание при запуске нового сервиса в продакшен.

https://jbd.dev/prod-readiness

https://medium.com/google-cloud/production-guideline-9d5d10c8f1e

#dotnet #mongodb
Как-то так повелось, что мы активно используем монгу(и любим ее всем сердцем). У монги есть 2 api. Не вдаваясь в детали, первое покрывает большинство кейсов по выборке документов и все CUD-операции, второе, а именно, aggregation framework, нужно для аналитических выборок и прочих сложных "селектов"(еще есть map-reduce, но это отдельная история). Исторически считается, что AF тормозит и предпочтение всегда отдавалось первому api.
Тут как-то выдалась свободная минутка и я полез разобраться как же в c# драйвере парни linq в монго-запросы транслируют и ушел с неприятным, но довольно логичным, инсайтом: linq транслируется в af-пайплайн. Вроде бы можно и закончить на этом, но чет меня дернуло сходить в коммьюнити с вопросом че щас по перфомансу af. Кароч, парни, щас движок AF сильно потюнили(курсоры-то всегда были одни и те же) и, если для простых выборок выигрыш у простого api еще какой-то есть, то более сложные запросы и удобнее и быстрее делать через AF
Кстати, если кто не знал, в вики монги на гитхабе много статей про кишки

Попалась на глаза подборка туториалов Робина Вирух про настройку React-проекта с нуля от создания package.json до настройки enzyme и hot module replacement.

Туториалы очень хорошие. В них всё написано по делу, понятно и аккуратно. Автор поддерживает их в актуальном состоянии; несмотря на то что некоторые статьи были опубликованы более двух лет назад, в них рассматриваются последние версии библиотек. Я немного запутался с перекрёстными ссылками, поэтому вот список ссылок на статьи в корректном порядке:

1. How to set up a modern JavaScript project
2. How to set up a Webpack project
3. How to set up Webpack with Babel
4. How to set up an advanced Webpack application
5. How to set up React with Webpack and Babel
6. How to test React components with Jest
7. How to test React components with Jest & Enzyme

Очень рекомендую пройти туториалы, если вы не настраивали сборку проекта самостоятельно.

#tutorial #webpack #react #jest

Не так давно пришла в голову мысль, что, поскольку я стал заниматься ФП из-за собственного интереса, а не каких-то объективных причин, у меня нет глобального понимания, почему оно "лучше" ООП — просто другая парадигма мышления.

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

Для тех, перед кем вопрос "ФП >? ООП" уже не стоит, статья может быть интересна кратким экскурсом в историю ООП и обилием достаточно забавных цитат.

Однозначно мем недели

Что творится?! В любом случае страдают обычные люди..😔

GitHub начал блокировать российских разработчиков.

Позиция GitHub
GitHub поясняет, что в настоящий момент он предлагает ограниченные услуги пользователям, проживающим в странах и регионах, которые находятся под санкциями, таких как Крым, Куба, Иран, Северная Корея и Сирия. Это означает в том числе ограниченный доступ к сервису публичных репозиториев — он может быть использован только для личной коммуникации, поясняется в электронном письме, которое получил от GitHub Анатолий Кашкин.

Источник

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

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 машин. Например куб. или эластик. Опа, а вот тут уже начинаются первые вопросы. Если мы обновим дистрибутив, сможет ли вообще наше приложение существовать в новом окружении? не посыпется по зависямостям? ничего лишнего не снесется? Все ли нужные пакеты запинены? не приведет ли новое ядро к тому что будет падать в корку приложение? Что вообще произойдет с подами куба если мы выведем ноду из обслуживания? А вдруг у нас настроено афинити и приложение жестко привязано к этой ноде и когда мы ее положим оно нигде не поднимется? С базами тоже интересно, нужно знать, достаточно ли у нас реплик, что шардинг разнесен правильно. В случае с тем же эластиком, например пишется такой плейбук, который дожидается пока не поднимется предыдущий сервер, прежде чем обновлять следующий.

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