Ну ладно, не всё: в основном статьи по DevOps, организации рабочего процесса, модным-молодёжным изменениям в подходе к инфраструктуре.
Разные статьи из интернетов и какие-то свои рассуждения
Отакот
#catops

Вот, например, очень старая статья про скейл Graphite.

Вообще, любые стораджи, где в основе лежат файлы, скейлить достаточно сложно. Ещё сложнее поддерживать доступность в случае падения одной из нод.

Однако, Graphite и Whisper используются в огромном числе компаний, так что статья свою актуальность совсем не утратила
#catops #monitoring #graphite

https://grey-boundary.io/the-architecture-of-clustering-graphite/

Прямо сейчас, а если точнее, этой ночью по Киеву, проходит очень большоая и известная конференция о мониторинге - Monitorama

А вот Oncall Handbook, который сделала одна из докладчиц.

Я ещё не успел прочесть его полностью, но уже ясно, что упор идёт именно на ночные онколы. Хотя для многих компаний это не редкость
#catops #monitoring #oncall

https://github.com/alicegoldfuss/oncall-handbook

Придётся немного прервать поток постов о мониторинге, но оно того стоит.

Украина возглавила список стран по колличеству пользователей, "застрявших" в Vim.

Ладно, ладно - у всех бывало
#vim

Полная статья:
https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-developers-exit-vim/

Но таки вернёмся к мониторингу

Ко мне когда-то обратились из министерства, кажется, это был МОЗ с просьбой посмотреть на один сервачок. Они запускали Open EdX для внутренних нужд на AWS EC2 и что-то он там периодически падал.

AWS отвечали стандартно: get a bigger instance. Что вполне логично с точки зрения AWS, но не рационально с точки зрения налогоплательщиков.

Но тут вопрос: куда смотреть? Одна VM, куда руками что-то установлено. Метрики самого AWS достаточно скудные. Конечно, есть atop, htop, iotop, iftop и ещё с десяток утилит для мониторинга систем, но если хочется красиво и с графиками - нужно что-то другое.

С ограничеными ресурсами на что-то глобальное не разгонишься, поэтому представлю вам прекрасную тузовину - netdata. Она и графики красиво строит и алертинг дашборд есть, и самое главное ресурсов не много съедает. Последнее критично, если вы в ситуации, подобной МОЗ

Больше тут:
https://github.com/firehol/netdata

Инстанс МОЗ я, кстати, так и не глянул. Они там как-то сами разобрались 🙂

Похоже, serverless лихорадка добралась до Украины.

Так что, если будете 25-го мая в Харькове, можно пойти послушать
#serverless #meetup #aws

https://hubhubhub.com/event/epam-kharkiv-open-devops-community-meetup-its-all-about-aws/

Вчера минут через 10 после того, как я запостил новость про Vim, у меня в личке спросили, что это такое.

Если вы всё ещё не освоили, наверное, лучший текстовый редактор в мире (да простят меня фанаты Emacs), для вас сделали вот браузерную игру с управлением в стиле Vim:
#vim #games

https://vim-adventures.com

Ещё не успели сломаться все копья вокруг термина DevOps, а его принципы уже пробуют прикрутить к дизайну.

Назвали это, врочем, весьма прозаично: DesOps
Примерное время чтения 3-5 минут
#devops #culture #design

https://medium.com/designer-hangout/what-is-design-operations-and-why-should-you-care-b72f02b47761

Пользуясь тем, что на канал подписаны все свои, я повыпендриваюсь самописным Sensu плагином для мониторинга Druid DB

Этот плагин, как и любой другой для Sensu, по сути является Ruby Gem'ой. Однако мне приятно, что первую в моей жизни гему не только скачали больше 300 раз, но и успешно использовали в продакшене.

Ладно, я сам успешно её использовал для prod Druid cluster. А вот про сам Druid я расскажу как-нибудь позже
#monitoring #sensu #ruby

https://rubygems.org/gems/sensu-plugins-druid

Ссылка на проект на GitHub
(ну и как обычно: issues & PRs приветствуются)

https://github.com/grem11n/sensu-plugins-druid

Интерактивная карта распространения IPv6 по странам.
Самоё большое проникновение, как ни странно, в Бельгии - 50.88% На втором месте Германия с 41.87%

Колличество устройств с предпочтением IPv6 в Украине - 0.47%

В целом же по миру ситуация с IPv6 не особо утешительная
#ipv6 #networking

https://stats.labs.apnic.net/ipv6

Сейчас проводится исследование аудитории Telegram.

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

https://www.google.com/url?q=https://goo.gl/forms/Q5voOROuJyMaxjvk1&sa=D&ust=1495806392574000&usg=AFQjCNG4XSNT7L1QpAqvjWlxHpVrkorLyw

Пятничный пост!

Для человека, который занимается серверами, в мире существует достаточно "компаний мечты". Некоторые из них очевидны, как Google или Netflix. Другие - не настолько, хотя технически они могут превосходить куда более известных игроков.

Одной из таких компаний вчера исполнилось 10 лет. В честь чего они подготовили интересную инфографику и прикольный ролик.

И да, там было бы очень круто работать, потому что с заявленым охватом, даже страшно представить, какая там инфраструктура :)

https://www.pornhub.com/event/10years

O'Reilly создали карту-пазл для продвижения книги о распределенных системах данных. И это очень крутой способ рассказать о книге. И уж точно не типичный для технической литературы ход

Карта напоминает схемы времен Великих георграфических открытый, хотя у меня была подобная карта Средиземья на форзаце книги

Больше об этом и о самой Data Intensive Applications book тут:

https://www.oreilly.com/ideas/drawing-a-map-of-distributed-data-systems

Оправившись от выходных, возвращаюсь к вам ^_^

Итак, на днях Chris Short написал статью "5 законов, которые должен знать DevOps инженер". Как и большинство статей разряда "Х вещей для Y", текст не несёт какого-то глубокого практического смысла, но поскольку большинство поисковых запросов "wtf is devops" приводят именно к таким статьям, имеет смысл немного о них поговорить.

№1: Забудьте "я не знаю"
Тут скорее о "не посылайте коллег лесом сразу". Потому что с одной стороны, фраза "я не знаю" действительно отдаёт упадком духа, с другой - человек не обязан знать всё на свете. Так что скорее пункт должен был называться: забудьте "это не моя работа"

№2: читайте мануалы
nuff said. Хотя если учесть, что наш народ читает инфструкцию только когда что-то сломалось, пункт нужный

№3: ищите перед тем, как спросить
Но одном из собеседований мне говорили, что на самостоятельный поиск решения стоит тратить ~2/3 времени, отведённого под определённую задачу. Практически это значит следующее: не бегите теребить коллег при первой заминке - вы просто будете раздражать людей и отвлекать их от работы; в то же время, не прикидывайтесь Робинзоном - вы не на необитаемом осторове. С точки зрения команды, гораздо важнее решить задачу в срок, даже если человек решил её не в одиночку. Об этом тоже стоит помнить

№4: Всё возможно. Никогда не говори никогда. Доверяй, но проверяй
3 тезиса соединены в один пункт. Вероятно, чтобы сохранить красивое число "5". Сами же тезисы оставим для мотивационных статей

№5: Признавай тезнический долг
И это, возможно, важнейший пункт. Потому что каждый раз, как в систему добавляют какие-то костыли и хотфиксы, технический долг растёт и в какой-то момент он может просто вас потопить. Поэтому очень важно отводить время на доведение до ума "склеек изолентой"
#catops #culture

Оригинал на английском:
https://opensource.com/open-organization/17/5/5-devops-laws

Правил сегодня небольшой Puppet модуль и осознал несколько вещей.

Во-первых, у Ruby есть очень много способов стрелять вам в ногу.
Во-вторых, есть такая приблуда - pyenv. Это как rvm, но для Python. Так вот, если у вас есть выбор использовать его или нет, не используйте.
И тем более не пытайтесь менеджить его Puppet'ом
#exp #catops

ссылка на pyenv отвалилась, так что вот отдельно:
https://github.com/pyenv/pyenv