DevOps *

После того как Иван познакомился с когортным анализом, он терпеть не мог любые виды слащавых метрик.

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

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

1 ноября 2017 года я стал руководителем рабочей группы разработки в отделе программных разработок Timeweb. А 12 ноября 2018 руководитель отдела спросил, когда же будет готова статья для Хабрахабр, потому что отдел маркетинга спрашивает, добровольцы кончились, а контент-план требует чего-то ещё)

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

8 ноября в главном зале конференции HighLoad++ 2018, в рамках секции «DevOps и эксплуатация», прозвучал доклад «Базы данных и Kubernetes». В нём рассказывается о высокой доступности баз данных и подходах к отказоустойчивости до Kubernetes и вместе с ним, а также практических вариантах размещения СУБД в кластерах Kubernetes и существующие для этого решения (включая Stolon для PostgreSQL).



По традиции рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде. Поехали!

Открыта регистрация на Слёрм-3.

Это трехдневный интенсив по Kubernetes для тех, кто ничего не знает о технологии или начал ее осваивать. Фишка интенсива в практике. Каждый участник сам создаст кластер в облаке Selectel, настроит его и развернет в нем приложение.

Слёрм-3 пройдет в Санкт-Петербурге 1–3 февраля 2019.

Зачем нужен Слёрм, если есть мануалы? Он экономит несколько месяцев, которые иначе вы потратили бы на чтение и самостоятельные эксперименты.

Краткая история вопроса.

Первый Слёрм прошел в августе 2018. Это был эксперимент, который удался, несмотря на кучу ошибок и проблем. Отчет.

GitHub использует MySQL в качестве основного хранилища данных для всего, что не связано с git, поэтому доступность MySQL имеет ключевое значение для нормальной работы GitHub. Сам сайт, интерфейс API на GitHub, система аутентификации и многие другие функции требуют доступа к базам данных. Мы используем несколько кластеров MySQL для обработки различных служб и задач. Они настроены по классической схеме с одним главным узлом, доступным для записи, и его репликами. Реплики (остальные узлы кластера) асинхронно воспроизводят изменения главного узла и обеспечивают доступ для чтения.

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

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

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

Перед тем как начать

• все, о чем здесь идет речь, в большей мере относится к дата-центрам и офисным сетям
• речь пойдет о проекте https://github.com/nihole/PSEFABRIC
• см. так же статью в которой изложены базовые принципы PSEFABRIC.

Идеальная система управления сетью

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

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

Можно ли этот подход перенести на сети и если да, то какая система управления была бы идеальной для сети?

Доброго времени суток!

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

В этой статье рассмотрим как можно без особых технических навыков и множества настроек развернуть бесплатный devops от Azure для своей компании (до 5 разработчиков бесплатно).

Ceph — это object storage, призванный помочь построить отказоустойчивый кластер. И все-таки отказы случаются. Все, кто работает с Ceph, знают легенду о CloudMouse или Росреестре. К сожалению, делиться отрицательным опытом у нас не принято, причины провалов чаще всего замалчивают, и не дают будущим поколениям научиться на чужих ошибках.

Что ж, настроим тестовый, но близкий к реальному кластер и разберем катастрофу по косточкам. Измерим все просадки производительности, найдем утечки памяти, разберем процесс восстановления обслуживания. И все это под руководством Артемия Капитулы, который потратив почти год на изучение подводных камней, заставил при отказе производительность кластера не падать в ноль, и latency не подскакивать до неприличных значений. И получил красный график, который ну сильно лучше.


Далее вы найдете видео и текстовую версию одного из лучших докладов DevOpsConf Russia 2018.

Прим. перев.: Этой статьёй, написанной Scott Rahner — инженером в Dow Jones, мы продолжаем цикл многочисленных материалов, доступно рассказывающих о том, как устроен Kubernetes, как работают, взаимосвязаны и используются его базовые компоненты. На сей раз это практическая заметка с примером кода для создания хука в Kubernetes, демонстрируемого автором «под предлогом» автоматического создания sidecar-контейнеров.


(Автор фото — Gordon A. Maxwell, найдено на просторах интернета.)

Когда я начал изучать sidecar-контейнеры и service mesh'и, мне потребовалось разобраться в том, как работает ключевой механизм — автоматическая вставка sidecar-контейнера. Ведь в случае использования систем вроде Istio или Consul, при деплое контейнера с приложением внезапно в его pod'е появляется и уже настроенный контейнер Envoy (схожая ситуация происходит и у Conduit, о котором мы писали в начале года — прим. перев.). Что? Как? Так начались мои исследования…

Всем добрый вечер!

Вот и осталось всего ничего (то есть один день) до запуска потока курса «DevOps практики и инструменты», а значит нам надо успеть за это время довыложить оставшиеся части статьи «Почему важна SRE документация».

Продолжаем.

Документы для Онбординга Нового Сервиса

SRE проводят PRR (production readiness review, обзор готовности производства) для проверки соответствия сервиса стандартам операционной готовности, а также чтобы убедиться, что владельцы сервиса понимают, как пользоваться знаниями SRE для управления большими системами.

Сервису необходимо пройти эту проверку до запуска в продакшн. (До запуска его поддерживают не SRE, а сама команда разработки.) Цель PRR на данном этапе — убедиться, что сервис будет удовлетворять минимальным стандартам надежности на момент запуска.

Каждый раз, когда приходится читать про очередного новорожденного убийцу айфона или фейсбука, невольно начинаешь улыбаться. За эти годы столько их уже было, а воз и ныне там. Поэтому, наткнувшись на очередную публикацию, где ключевой мыслью была идея о том, что наступающая эпоха бессерверных вычислений приложений (Serverless) «съест» DevOps, скепсису не было предела.

С приходом .Net Core у нас появилась прекрасная возможность не только запускать наш код на разных ОС, но и тестировать его на разных ОС. А что может быть лучше Docker при работе с разными ОС?

Привет, друзья. Так как мы сами активно используем OpenStack, то решили позвать к себе в гости других адептов технологии на @OpenStack Meetup, который мы делаем совместно с российским сообществом OpenStack.

Встреча пройдет 30 ноября (пятница) в 19:00 в московском офисе Mail.Ru Group (Ленинградский проспект, д. 39, стр. 79).

Приглашаем всех, кто работает с OpenStack и кого интересуют особенности платформы. Среди спикеров – «Яндекс.Деньги», Canonical и Mail.Ru Group. Начнет встречу амбассадор OpenStack в России Илья Алексеев, который поделится с гостями новостями недавнего OpenStack Summit в Берлине.

Регистрация обязательна и закрывается 28 ноября в 23:59 (или раньше, если закончатся места).

Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработки. Ее не любят за тяжеловесность и плохую реакцию на изменения. Это напрямую влияет на актуальность продукта и увеличивает ТТМ (time-to-market), выливаясь в дополнительные затраты. Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.

Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд? Как достичь той уверенности в продукте, которую дает долгое, исчерпывающее тестирование как в waterfall? В этом посте мы поделимся своим решением этого вопроса.

Очередная статья в серии «Инструменты мониторинга Logicify» рассказывает о Grafana. Это программное средство мы используем для визуализации и анализа данных как внутренних, так и внешних проектов. Статья может быть полезна техническим директорам, разработчикам, DevOps, системным администраторам, менеджерам проектов, а также всем заинтересованным лицам.

После выделения DevOps внутри компании «Неофлекс» в отдельное бизнес-направление команда стала активно наращивать экспертизу и делиться найденными источниками знаний друг с другом. В этом посте я поделюсь с вами личным опытом погружения в тему и наиболее интересными ресурсами.

Основными источниками информации по теме стали следующие:

• Интернет-ресурсы – как независимые, так и компаний разработчиков
• Статьи и презентации
• Литература
• Конференции
• Программы обучения – как платные, так и бесплатные

Вот и наступила осенне-зимняя пора. За окном дожди и желания проводить время на открытом воздухе все меньше и меньше. И вот приходит мне сообщение от товарища "А давай поиграем в Lineage 2?". И опять я, поддавшись ностальгии, согласился. Выбрали мы свеженький сервер на ру-офе и создали персонажей.

 
В отличии от World of Warcraft в Lineage 2 совершенно другая система добычи игровой валюты. Нужно круглыми сутками охотиться на монстров с целью получения наживы. Для меня было даже открытием, что для некоторых людей RMT (Real money trading) является чем то вроде работы. Также, в игре присутствует экономика, которую формируют игроки. Иными словами, можно заработать на купи-продай или же покупать дешевые ресурсы, из них делать вещи и продавать с наценкой. Так как для нас игра остается чем то вроде отдыха именно такой способ получения игровой валюты был выбран нами.

Чтобы покупать и продавать предметы игрок должен находиться online (Скриншот сверху). Соответсвенно, кто-то хочет побыстрее продать (дешевле) а кто-то побыстрее купить (дороже). А что если разница продать — купить положительная? Как раз этот пример и будет рассмотрен в статье как итог.

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

Spoiler:
В статье будут использованы следующие технологии
Docker, DigitalOcean, NodeJs, Ktor, Prometheus, Grafana, Telegram bot notification

[часть 2 из 2]

[часть 1 из 2]

Как нам это удалось

Мы решили перейти на GCP, чтобы повысить производительность приложений — увеличив при этом масштаб, но без существенных затрат. Весь процесс занял более 2 месяцев. Для решения этой задачи мы сформировали специальную группу инженеров.

В этой публикации мы расскажем о выбранном подходе и его реализации, а также о том, как нам удалось достичь главной цели, — осуществить этот процесс максимально гладко и перенести всю инфраструктуру на облачную платформу Google Cloud Platform, не снижая качества обслуживания пользователей.

И снова здравствуйте!

Представляем вам открытый урок курса «DevOps практики и инструменты» на тему «Инфраструктура как код». Игорь Курочкин, преподаватель курса, на пример этой практики рассказывает как можно улучшить взаимодействие команд, ускорить процесс поставки ПО и снизить количество ошибок и показывает основные практики и инструменты для разработки инфраструктурного кода.


Если есть вопросы и комментарии можете оставить их тут или зайти на день открытых дверей и пообщаться с преподавателями курса там.

Всем привет!

Мы допечатали книгу «Философия DevOps», а также планируем делать и новую книгу на эту тему.


Немало копий сломано по поводу того, чем является и чем не является DevOps, а также о соотношении DevOps и непрерывной интеграции. Поэтому мы просим вас максимально объективно высказаться, разделяете ли вы точку зрения сегодняшнего автора Адама Маккея (Adam Mackay) относительно сути DevOps — либо, на ваш взгляд, предложенная им картина в чем-то неполна или ангажирована?

Читаем и комментируем!