Вот мне начали приходить запросы о темах. И первая звучала как: "что нужно знать о DevOps бекэнд программисту, чтобы наступило вселенское счастье".

Во-первых, DevOps — это методология, а не какая-то абстрактная должность. Соответственно, чтобы любому разработчику получить наибольшую отдачу от этого, надо даную методологию принять. Проблема в том, что при упоминании DevOps, каждый представляет что-то своё. Так что существует огромное число мнений на счёт того, как делать правильно.

Однако, есть несколько моментов, в которых практически все сходятся. С точки зрения разработчика, вы должны подумать хотя бы вот о чём:

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

- сокращайте срок релиза. Релиз вообще не должен быть каким-то событием. Аж в 2009 году John Allspaw и Paul Hammond из Flickr представили доклад 10 deploys per day. Это было 8 лет назад и сейчас колличество деплоев в компаниях возрало в разы. Короткие релизы позволяют быстрее найти проблему (если появится) исправить её или в крайнем случае релиз откатить

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

- общайтесь между собой. С одной стороны, офисы open space особо не улучшают общение в коллективе, с другой вам и не надо быть закадычным другом для всех коллег, вам не обязательно ходить вместе пить пиво. Достаточно понимать, что вы преследуете одну цель.

- учитесь на своих ошибках. Amazon представил. Есть метод "5ти почему". Например, недавние проблемы с AWS S3 был спровоцирован человеческим фактором, но никого после этого не уволили. Потому что как говорится "мы только что вложили несколько миллионов в твоё обучение"

- автоматизируйте это. Это к слову об ускорении времени между релизами. Для этого уже есть куча инструментов: CI/CD сервисы (о них как-нибудь напишу отдельно), сервисы для Continuous Code Analysis и прочее

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

В довесок рекомендую вам почитать The Phoenix Project — единственную известную мне художественную книгу о DevOps. Плюс, Site Reliability Engineering. Есть ещё куча книг по данной тематике. Которыми я буду с вами по ходу пьесы делиться.

И да, как я говорил, мне можно писать и спрашивать об интересующих вещах. Ну а я в свою очередь расскажу о чём смогу в силу своей экспертизы. Вот вам даже специальный бот для этого: @AskCatOpsBot
#culture #devops

17 июня (эта суббота) пройдёт очередной Kyiv DevOps meetup

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

В общем, будет полезно не только матёрым 0дминам, но и разного рода разработчикам, студентам и желающим "вАйти". Кроме того, вся эта движуха бесплатна, по крайней мере раньше так было. Главное — зарегистрироваться через MeetUp. Ссылку я скинул.

Welcome!
#event

Как-то мне рассказали о такой интересно штуке, как exception driven development. Это когда вы начинаете налавливать эксепшены и просто таки строить на них всю логику приложения. После такого в логе можно найти что-то типа:

 This is not an error. Even foobar captured

Так вот, такого делать не надо. Анти-патерны окружают нас на самом деле повсюду и не только в сфере разработки приложений. Это я к тому, что завтра я бы хотел написать либо о анти-паттернах, либо о логах — ещё не решил.

А пока почитайте про другие пагубный паттерны в статье с прекрасным названием "Asshole-driven development"
#anti-pattern #development

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

Зато Puppetlabs тут сделали опрос, по которому вы можете определить, насколько глубоко DevOps практики засели в вашей компании.

Там всего 17 вопросов и мне выпало 'Advanced'. Хотя у нас далеко не все хорошо, там такой опрос, что получить не 'Advanced', наверное, сложно

С другой стороны, на основании подобных опросов они скорее всего делают ежегодный отчёт, так что ваш голос улучшит выборку

Как раз для пятницы. Кстати, https://www.commitstrip.com прикольный, почитайте)

Тем временем вышел апдейт Atom'а. Они наконец-то сделали поддержку Git. В MS Visual Studio Code, вроде, изначально была.

Кроме того, есть интеграция с GitHub: можно ресолвить конфликты и просматривать пул реквесты.

Создать issue прямо из редактора, к сожалению, пока нельзя
#editors

Atom Editor 1.18 Released with Rich Git Integration
😁 goo.gl/3v7YVr

Ну и ещё подъехали записи с очередного SRECon

Опубликованы видеозаписи докладов с SREcon 2017 Asia. Отдельно хотел бы обратить внимание на доклад Golang's Garbage про некоторые особенности работы сборщика мусора в Golang.

Список докладов со ссылками на видео можно найти на официальной странице конференции:
https://www.usenix.org/conference/srecon17asia/program

#srecon #videos #sre

Так вот, о логах. Я бы не хотел зострять на них внимания с точки хрения разработчика. Уже очень много было сказано о том, что логгировать необходимо только значимые события, дифференцировать разные уровни (ERROR, WARN, INFO, DEBUG, etc) и стараться стандартизировать сообщения. Об этом вы можете почитать здесь или тут

Я бы хотел акцентировать на том, что как бы вы их не писали, ходить и вручную собирать сообщения по серверам — плохая идея. Да и вообще, хранить их там долго — не очень хорошо. Логи могут тупо забить весь диск. Думаю, все слышали про ELK (elasticsearch + logstash+ kibana) для сбора, поиска и визуализации системных сообщений.

Это удобно, во-первых, потому что вам не надо рыскать по пачке машин в поисках ошибки, во-вторых, потому что упрощает capacity planning. Вы без проблем сможете прикинуть, сколько места вам понадобится под это дело, как часто надо чистить старые сообщения и т.д

Но всё-таки иногда в компаниях работают "по-старинке". Из моей практики, при этом подходе есть пару советов:

- ротируйте логи не по времени, а по размеру. Допустим, вы проводите ротацию раз в сутки и держите записи за неделю. Не исключён вариант, что произойдёт непредвиденное событие или же кто-то включит DEBUG mode и всего за пару часов лог вырастет до нескольких Гигабайт.
- не делайте ротацию логов внешней зависимостью. Да, существует logrotate, можно чистить логи по крону, но много лучше, когда этим занимается само приложение. По крйней мере, log4j в Java прекрасно это умеет

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

Ну и под конец, статья JetRuby со сравнительным обзором Graylog и ELK, наверное, самых известных системах централизованного хранения логов for free
#logs #elk #graylog

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

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

Серьёзно, это очень интересно! Всё равно, что смотреть фэнтезийный сериал, только тут персонажи реально могут помереть волею случая и дайсов. Плюс, поскольку прямо таки на видео не происходит прямо такого уж экшона, можно слушать в фоне. Я даже работаю иногда под это дело. Кстати, неплохо разгружает мозг

Смотрю тут

И нет, это не реклама. Просто хочу поделиться реально интересной штукой, а то все дотка, да дотка

P.S. Отдельно у них хочу выделить вот эту серию. Я в неё реально залип. 2-3 сессии, правда, у них идёт раскачка, зато потом огонь!

Очередная бесплатная книга по Ansible. Собственно, написана ими самими

https://www.ansible.com/smart-devops-ebook?utm_campaign=DevOps&utm_content=55588598&utm_medium=social&utm_source=twitter

Вдруг кому пригодится

В продолжение темы логов, статья человека, который заменил Logstash в ELK стэке на Rsyslog и почему ему с этим хорошо:

tl;dr: rsyslog быстрый и простой. В довесок, он выкинул из своей цепочки Redis, а уменьшение числа движущихся частей в системе -- это хорошо
#logs #elk

Несколько постов назад я писал о системах управления конфигурациями, но вскользь упомянул, что можно и без них, в принципе.

Вот, можете почитать статью Жени Брикмана о том, как управлять инфраструктурой лишь при помощи Terraform. Immutable infrastructure as is.

И вообще, я очень рекомендую его блог всем, кто хочет познакомиться с Terraform или лучше его понять. Кроме того Евгений написал о нём книгу, но книга платная.
#terraform

История о том, что встроенный в AWS ElasticSearch as a Service не всегда работает.

Ну и поскольку у вас нет админ доступа к потрохам Эластика, быть уверенным на 146% в том, что там происходит вы не можете.

З.Ы. Мне же тем временем пришёл инфайт в DataDog. Потому что у компании дофига бабла. Пока не крутил его: посомтрю, что там — расскажу
#elk #aws

Есть такая книга — Red Team Field Manual. Это название производно от аббревиатуры RTFM (а не наоборот) что означает Read The Fucking Manual. У этой фразы даже есть своя собственная странца в Википедии. Видимо, в мире действительно реально есть много желающих делать что-то не вникая в матчасть.

Так вот, данная книга по сути своей является просто сборником часто используемых команд с кратким описанием. Но в отличии от стандартных man pages, многие команды приведены с наиболее часто используемыми ключами (ну вот никто не делает просто df, вегда df -h)

Книгу даже можно купить на Amazon. Только вот найти там что-то конкретно — задача не из лёгких.

В честь этого, GitHub юзер leostat написал поиск по базе RTFM, которую составил на основании книги. Enjoy!
#unix #linux #rtfm #books

Занимательная заметка Joe Shaw о том, почему использовать defer Close() в Go приложениях — не лучшая идея.

И хотя в примерах рассмотрен конкретно Go, механизмы работы с I/O описаны на уровне ОС и будут общими для приложений на любых языках. Так что Close() вполне может вернуть ошибку, хотя Write() закончился успешно (как нам показалось)
#golang

Я вот засел писать два более-менее больших поста для канала, но никак не доведу это дело до ума. Так что полистайте пока GitHub Национального Агентства Безопасности США

https://nationalsecurityagency.github.io/

А тем временем, в nix-подобных ОС нашли очередную дыру, которая позволяет повысить привелегии. Суть в том, что если у вас рядом расположены stack и heap, то при перезаполнени кого-то из них, данные могут быть переписаны. Так данные из heap могут попасть в область stack и наоборот.

Во имя избежания сей напасти, разработчики сделали т.н. guard-page. Как раз в ней дыры и нашлись.

Больше о разнице между stack vs heap можно почитать тут
#security #nix

Вот тут подробней про механизм уязвимости описано:
https://nullprogram.com/blog/2017/06/21/