Пятничный деплой
4.49K subscribers
1.42K photos
29 videos
167 files
7.8K links
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://xn--r1a.website/s/count0_digest
Download Telegram
Этот доклад выглядит очень вкусно. Зайдите на сайт hastic.io - посмотрите
Смотрите запись или трансляцию - демо очень крутое
Пока картина такая - есть продукт который позволяет слать хук при появлении «аномалии» - паттерна на графиках из датасорса. Задать такую аномалию можно или с помощью плагина в графане - просто выделив на графике участок (выглядит очень эффектно) или «закодить» паттерн на питоне
Продукт - огонь, докладчик тоже. Надо тестить (продукт конечно же)
Вот и отличнейший конспект подъехал
Очень грамотные рассуждения про отказы
Нарвался тут на обсуждения про допустимость ошибок в ИТ индустрии. Дескать, во многих сферах из-за ошибок и косяков гибнут люди, а в ИТ часто косячить это нормально.

Во-первых, далеко не в каждом бизнесе встречается толерантность к косякам со стороны ИТ. Одна из причин “медленного” производства ИТ продуктов в таких компаниях, как банки, госсектор, добыча ресурсов, фин сектор, трейдинг, оборонка, космическая и авиационная отрасль и т.д., в том, что обновления софта проходят (либо должны проходить) многодневную скрупулезную проверку качества поставляемого продукта. Иными словами, там полный ITIL/ITSM с change management’ом, когда под малейший патч подписывается огромное количество ЛПР.
Во-вторых, похожим образом ведут себя разработчики криптовалют из топ 5, в частности разрабы Bitcoin. На кону не только их репутация, как спецов, но и репутация самого битка, которая и так страдает от нападок экономистов из общего сектора классических фин. инструментов.

Я бы сослался на некомпетентность менеджеров и инженеров, считающих, что косячить можно и даже нужно, если б сам не отработал в e-commerce конторе полтора года, где такой культурный код применялся.

Те, кто меня давно читает, помнят мою историю, когда я облажался с настройкой DHCP серверов, задав неправильные октеты CIDR в Puppet. Тогда это проверилось serverspec’ом и code review, но косяк все равно прошел и обрушил половину серверов в продакшене. Я отделался лишь тем, что с позорным лицом (не хватало еще тетки с колокольчиком из Игры Престолов) ходил с печеньями от комнаты к комнате, раздавая их и рассказывая, что я наделал и почему так больше не буду.

Впрочем не я первый и не я последний, кто ломал прод в этой конторе. В employee handbook для сотрудников Coolblue Tech фигурировала строчка: Fail more often.
Agile Coach, проводивший для меня и других новичков тренинг по Scrum, говорил: “Если вы боитесь что-то трогать в текущей инфраструктуре, например, обновлять ОС на серверах СУБД - делайте это чаще.”

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

Уставы ICAO (Международная Организация Гражданской Авиации) написаны кровью. Каждый разбившийся самолет, каждый сбитый малайзийский боинг служат поводом для пересмотра и обновления правил, которым следуют (и должны следовать) все авиаперевозчики.

Да, в разработке веб проектов самый страшный косяк приведет максимум к упущенной прибыли и низкому NPS, но каждый косяк, откуда бы он ни пришел и как часто бы не проявлялся, служит возможностью сделать продукт более надежным.

А вот если в конторе часто косячат, ломают и роняют, но это не приводит ни к каким заметным улучшениям, то стоит задаться вопросом, а стоит ли там работать. Если только не вы тот самый специалист, который часто косячит. Тут, как раз, все очевидно.
Ребята из Devops Moscow (на самом деле есть еще более давнее сообщество hangops_ru - пусть меня поправят если я ошибаюсь) время от времени записывают что-то вроде вебинаров-митапов по DevOps и около-DevOps темам. Я смотрел несколько записей и это действительно очень интересно и полезно. Сегодня вечером, в 21-00 мск будет очередное мероприятие, основным «докладчиком» на котором станет Олег Сорока, который расскажет про «Факторы, влияющие на скорость, качество, эффективность и прибыльность разработки и почему ваш менеджер делает всё не так» http://youtu.be/Oh5tAvq-ysQ настоятельно рекомендую - в свое время именно их вебтрансляции помогли мне составить представление о культуре
Ссылку поправил
Forwarded from Go Дайджест
Невероятный пост от Вани Данилюка, про то, как нужно фигачить проекты выходного дня. 🥳 Тут и про gomobile и про фронтенд на Go. Просто прочитайте, читайте и будте как Ваня, фигачте так же круто. 😎
https://divan.github.io/posts/animatedqr/
Тем временем, Selectel тоже вышел на тропу Kubernetes
На Uptime доехать у меня так и не получилось сегодня, но информацию я вам раздобыл (огромное спасибо тем сорокам, которые мне на хвосте ее приносят). Ну и автору конспектов, конечно!
https://github.com/ikurochkin/uptimeday-3-2018/blob/master/README.md
Эта тема действительно важная
Первая часть из серии статей про "Kubernetes Pod Networking" от ребят с weave. Акцент будет делаться на сеть в AWS, но первая часть общая про сеть Kubernetes
https://www.weave.works/blog/introduction-to-kubernetes-pod-networking--part-1