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

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

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

Итак, у нас будет вечер аналитики. Для затравки, DOU сделали очередной "портрет украинского айтишника". На русском и с весёлыми картинками

Дальше уже более взрослая инфографика: PuppetLabs подготовили отчёт о состоянии DevOps на 2017 год. Там достаточно большой документ с графиками, описанием методик измерения и высокоуровневыми выводами. Отчёт можно скачать по ссылке, но также прикреплю его сюда.

Ключевые тезисы:
- лидеров рынка объединяют 5 основных качеств: видение, взаимопомощь, стимуляция ума, общение и взаимное признание в коллективе
- Команды с высокой отдачей достигают одновременно и большей производительности, и лучшей стабильности
- Автоматизация — ощутимое улучшение для организации
- Методология DevOps применима для любых организаций
- Слабо связанные команды достигают результата быстрее (за счёт уменьшения простоя при ожидании зависимостией)
- Бережливый (lean) продакт-менеджмент ведёт к лучшей производительности

Но в отчёте ещё много чего, enjoy!
#devops #catops #culture

Вот мне начали приходить запросы о темах. И первая звучала как: "что нужно знать о 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

Слайды доклада Matthew Skelton об организации технических команд с DevOpsCon - Berlin, которая прошла в этом месяце.

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

Самое интересное начинается с 35-го слайда. Там, кстати, приводят в пример сайт DevOpsTopologies, где рассмотрены паттерны и анти-паттерны перехода к даной методологии.

И кроме того, рекомендую размышления Ed Coffey о том, что DevOps — это больше, чем просто автоматизация. Там коротенькая заметка на пару минут. Вроде и очевидно всё, но на деле я вижу десятки вакансий с лычкой "DevOps engineer", где ищут человека, который придёт и настроет Puppet/Chief/Ansible/Salt (нужное подчеркнуть)
#culture #devops

📚 Не спать, всем читать!

Тут на Humblebundle бандл для DevOps от Packt завезли, загляните, возможно заинтересует что-то:

https://www.humblebundle.com/books/devops-books

#фидбечат #devops #книга

Chernobyl DevOps: Software Engineering, Disaster Management, and Observability -- статья о том, что DevOps культура может вынести из Чернобыльской трагедии.

+ обсуждение на Reddit. Не конкретно этой статьи, но скорее впечатлений systems engineers от просмотра сериала от HBO

#culture #devops

A great article on the DevOps culture from one of our subscribers.

The article is about why we probably failed to advertise DevOps properly and worsened the problem we tried to solve.

P.S. You can share articles and other useful materials in our chat

#culture #devops

From our subscriber.

How developers can be their own operations department is a story of DevOps evolution in a single company.

This article doesn't provide any answers on how you should run your operations or organize your teams. However, it gives some historical context. The story of Flipp company is very similar to what happened with the industry as a whole.

If you want to get an insight on how DevOps movement emerged and why it has become so popular - you're welcome to read this one.

P.S. You can propose an article in via chat

#culture #devops

Sup!

As some of you may know, I'm a part of the DevOps Days Kyiv organizer committee. Last year we managed to raise more than €100k for various Ukrainian foundations.

This year we want to have a conference as well! Moreover, we want to focus on the Ukrainian experience specifically in regard to the disaster recovery.

So. Maybe, you had to migrate your infrastructure abroad during 2022, maybe you have an interesting story of how to organize team work during blackouts, or maybe you had to re-write your disaster recovery policies from scratch.

If this is your case, the Call for Papers. We would be happy to hear from you!

#devops

While I'm editing the audio from our previous voice chat, Denys has already uploaded a new episode of his podcast (in Ukrainian) with me as a guest.

We have talked about SRE, its origins and limitations.

Also, make sure to subscribe to Denys' channel on Telegram as well as on YouTube to get the new notified when new episodes are there!

#sre #podcast

Puppet Labs have issued a new State of DevOps 2023 report.

This time it’s focused on Platform Engineering and how it helps organizations to achieve their goals and move further with their DevOps journey. Key takeaways (opinionated):

- While DevOps helps to foster collaboration and delivery velocity inside teams, platform engineering helps to increase the delivery velocity across the organization.
- Companies that have implemented platform engineering approach are satisfied with it. Also, companies that have platform teams for longer period of time are more satisfied, which is a good sign.
- Platform engineering treats infrastructure (observability, CI/CD, etc.) as a product, not as project. Therefore, platform teams benefit from a product manager position within a team.
- Yet, about a half of respondents have reported that their senior leadership is still concerned about the topic of platform engineering or confused about it.
- Centralized platform team is more common compared to decentralized and people who work in a centralized structure are more satisfied.
- Organizations plan to hire engineers to work on their internal platforms. So, you‘re safe :)
- 01 Normalize the technology stack => 02 Standardize and reduce variability => 03 Expand DevOps practices => 04 Automate infrastructure delivery => 06 Provide self-service capabilities => ???? => PROFIT!!1

#report #culture #platform_engineering #devops

An incredible story by Juraj Majerik.

In his spare time he has created an Uber-simulation app. With Go on backend and React on front-end.

He didn’t just created an app but also deployed it and configured the infrastructure and monitoring for it. Moreover, he has documented the entire process. So, you can pretty much follow his journey.

There is also a neat summary of this project by Gergely Orosz (Pragmatic Engineer). Here is a part I want to highlight:

I really like how this project showcases _just_ _how much time_ can go into infrastructure setup. At companies with dedicated platform teams, those teams take exactly this kind of load off other teams building greenfield projects.

Both as an engineer, and especially as an engineering manager, don’t forget there’s a real cost to setting up and then maintaining infrastructure. Much infrastructure work is invisible as it does not involve commits, and most engineers won’t document the time they spend on these tasks, like Juraj has. But this is work that still needs to be done!

#programming #devops

Some Friday material (also, from our subscribers, btw).

DevOps is Bullshit.

Now, once you've got clickbaited, let's talk. The premise of this article has been already repeated many times in different words: a single person cannot know everything and be good in everything, job-specialization is actually good, you can have good enough Jacks of All Trades in the beginning, but it doesn't scale.

The answer that this article provides is to build platforms. Internal platforms, specifically. You know, do Platform Engineering. And I fully agree with this statement. Yet, this article comes from a company that sells you an "IDP as a Service". So, you can clearly see some vested interest here. What I dislike specifically about this article is that instead of striving for standardization, a good platform should "accommodate all the various needs and configurations". I mean, if you sell it to others, it makes sense. If you are building an internal platform, why would you do that?

Anyway, nice Friday read. Here's a reaction video by Primeagen (this is how I actually "read" this article).

Also, if you have any interesting things to share - welcome to our chat! Chat is in Ukrainian, tho.

#devops #culture #platform

​​There was an interesting talk at CfgMgmtCamp 2024 about non blocking code reviews.

The good thing is that there’s also an article on this topic from the author

The general idea is that not all the code changes require a code review, especially when there are enough safety nets configured.

As a result, smaller code changes simply sit there and wait for be reviewed, which may take some time, especially in a remote setup.

The solution is to allow such changes as they are and add them to a backlog of pending reviews.

There are more details in the article. Also, here’s a picture from that presentation that kinda captures the spirit of this idea.

#programming #culture #devops