Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#подборки</a>

2 <ul><li>15 июн 2021</li>

3 <li>0</li>

4 </ul>Собрали 6 отличных материалов о DevOps из англоязычных источников - внутри расширенные саммари. Будет интересно и новичкам, и опытным специалистам.

5 В бэкграунде - программирование, французский язык, академическое рисование, капоэйра. Сейчас учит финский. Любит путешествия и Балтийское море.

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

7 Где читать:на сайте<a>Harness</a>.

8 Зачем читать:чтобы понять разницу между DevOps и SRE и разобраться в метриках, которые в них используют.

9 DevOps и SRE становятся всё популярнее, а специалисты в этих областях - всё более востребованными. Но важно понимать, чем они различаются и как с ними работать. Об этом и рассказал Рави Лахман - евангелист Harness, который успел поработать в Red Hat и IBM.

10 Цель DevOps - решить проблему в коммуникации между разработчиками и командой эксплуатации. SRE, или Site reliability engineering, - это в первую очередь поддержка безопасности и надёжности системы.

11 Если говорить про скиллы, то DevOps - это системные инженеры, которые занимаются разработкой, а SRE - разработчики, которые вкатились в проблемы эксплуатации ПО. И в обеих методиках важны метрики - ведь тяжело улучшить то, что ты не можешь измерить. Обычно используют три показателя: SLA, SLO и SLI.

12 <ul><li>SLA - это соглашение об уровне услуг, то есть ожидания клиента от сервиса. Клиентом могут быть как люди, так и другие системы. Пример SLA - это требование 99% аптайма.</li>

13 <li>SLO - это цели, которых надо достичь, чтобы выполнить SLA.</li>

14 <li>SLI - это метрики для измерения SLO.</li>

15 </ul>Но в DevOps есть и специфические метрики:

16 <ul><li>Lead Time- это время на реализацию, то есть между проверкой кода и его развёртыванием.</li>

17 <li>Deployment Frequency - частота развёртывания. Чем выше этот показатель, тем эффективнее процесс.</li>

18 <li>Mean Time to Restore (MTTR) - среднее время восстановления, то есть возврата к прошлому уровню работоспособности.</li>

19 <li>Change Failure Percentage - процент неудачных изменений.</li>

20 </ul>Кроме того, Рави добавил подробную сравнительную таблицу SRE- и DevOps-специалистов и рассказал, как лучше организовать их работу.

21 Где читать:статья Сэма Бочетты на <a>InfoQ</a>.

22 Зачем читать:чтобы узнать, почему DevOps становится всё популярнее.

23 DevOps набрал огромную популярность в последние годы и пока не собирается сдавать позиции. Вот несколько трендов, которые способствуют его популярности:

24 <ol><li>Тренд на микросервисыи контейнеризацию, угасание монолитных архитектур.</li>

25 <li>Облачная разработкакак стандарт.</li>

26 <li>Kubernetesи контейнеризация, которые позволяют забыть о жёстком контроле и выстроить работу по принципу прозрачного творческого беспорядка.</li>

27 <li>Agile.Конечно, это не новый тренд, но гибкие методики - настоящее разработки, и от них никуда не деться.</li>

28 <li>Автоматизация выпуска ПО.А в этом процессе команды разработки и эксплуатации должны плотно сотрудничать.</li>

29 <li>Отказоустойчивость, а не защита. DevOps и DevSecOps поменяли подход к безопасности: каждый элемент теперь рассматривается как потенциально уязвимый, а главная цель - не дать уязвимости повлиять на другие элементы системы.</li>

30 <li>Вредоносное ПО.С гибкостью DevOps пришли и новые вызовы, в том числе для безопасности. Вредоносные программы теперь поражают даже облачные системы - и в борьбе с ними DevSecOps особенно актуален.</li>

31 <li>ИИ имашинное обучение.Эти сферы тесно связаны с развитием автоматизации, а значит, могут сильно повлиять и на DevOps.</li>

32 </ol>Где читать:обсуждение на <a>Reddit</a>.

33 Зачем читать:чтобы узнать о неочевидных особенностях и инструментах для разработки на Kubernetes.

34 Топикстартер хотел узнать, как лучше всего создать среду на Kubernetes, которая позволит запустить реплику для локальной разработки или отладки. Docker Compose показался ему не особо надёжным - к тому же он сложноват в поддержке. А Minikube не подошёл из-за низкой скорости.

35 Советы комьюнити - кратко:

36 <ul><li>Использовать отдельные кластеры для разработки и тестирования.</li>

37 <li>Разные пространства имён в одном кластере.</li>

38 <li>Kind.</li>

39 <li>Telepresence.</li>

40 <li>Canonical.</li>

41 <li>Terraform.</li>

42 </ul>Где читать:интервью на <a>JAXenter</a>.

43 Зачем читать:чтобы узнать о будущем и проблемах DevOps.

44 Опрос State of DevOps Report показал, что многие тренды 2020 года будут уже не так актуальны в 2021 году. Например, инвестиции в автоматизацию, облака и общую модернизацию.

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

46 Из интересного:

47 <ol><li>Продвинутые в DevOps компании оказываются более продуктоориентированными и чаще используют внутренние платформы.</li>

48 <li>Выяснилось, что DevOps и управление изменениями (change management) вполне себе коррелируют: чем сильнее в компании развит DevOps, тем успешнее управление изменениями. Раньше их считали несовместимыми.</li>

49 </ol>Где читать:статья на <a>bmc</a>.

50 Зачем читать:чтобы узнать об основных практиках DevOps и стандартных структурах DevOps-команд.

51 Один из главных приоритетов DevOps - выпускать ПО чаще и с хорошим качеством. В этом отлично помогает автоматизация процессов. Примеры:

52 <ul><li>Непрерывная интеграция.Вместо ручного обновления и тестирования кода разработчики загружают изменения в центральный репозиторий. Там он собирается и тестируется автоматически.</li>

53 <li>Непрерывная доставка.Это что-то вроде расширенной версии непрерывной интеграции. После сборки и тестирования код автоматически проверяется, пока не будет одобрен для продакшена. Популярные инструменты: Jenkins, Bamboo, Travis, TeamCity.</li>

54 <li>Непрерывное тестирование.Помогает обнаружить потенциальные проблемы на самой ранней стадии. Если код не проходит автоматические тесты, он не попадёт на функциональное тестирование, а разработчики получат уведомление о проблеме. Популярные инструменты: Selenium, Travis, Appium.</li>

55 <li>Непрерывный мониторинг.Ещё одна практика для поиска проблем. Чаще всего отслеживаются нагрузка на процессор и память, место на диске и действия клиентов. Популярные инструменты: Nagios, Sensu, Prometheus.</li>

56 <li>Инфраструктура как код.Практика, в которой инфраструктура управляется через код, а не вручную. Её можно встретить в компаниях, полностью работающих на облачных технологиях.</li>

57 <li>Микросервисная архитектура.Такое ПО состоит из небольших независимых компонентов, у каждого из которых есть своя функция. Микросервисы повышают надёжность программы, а добавлять и обновлять функции становится проще.</li>

58 </ul>Структура DevOps-команд зависит от стиля менеджмента конкретной организации. Вот девять самых популярных структур:

59 <ol><li>Команды разработки и эксплуатации плотно сотрудничают между собой. Идеальная ситуация :)</li>

60 <li>Команда эксплуатации интегрирована в команду разработки. Такая структура принята в Facebook* и Netflix.</li>

61 <li>Команда эксплуатации построена по модели "инфраструктура как услуга".</li>

62 <li>DevOps как внешняя служба.</li>

63 <li>Временная DevOps-команда.</li>

64 <li>Команда поддержки DevOps.</li>

65 <li>SRE-команда, которая оценивает, отвечает ли ПО всем стандартам.</li>

66 <li>Сотрудничество с помощью контейнеризации.</li>

67 <li>Сотрудничество разработчиков с администраторами баз данных (DBA).</li>

68 </ol>Где читать:статья на <a>Medium</a>.

69 Зачем читать:чтобы узнать о главной организационной проблеме в DevOps и методах её решения.

70 Когда команды разработки и эксплуатации разделены, работа замедляется, а между командами может возникнуть нездоровая конкуренция или даже враждебность. DevOps решает эту проблему, позволяя быть продуктивнее и не обращать внимания на организационные ограничения.

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

72 Люди думают, что DevOps-команды работают независимо друг от друга. Однако на практике они взаимосвязаны - как связаны и отдельные компоненты системы, которыми они занимаются. По статистике, 70-80% неожиданных проблем происходит из-за запланированных изменений в "соседнем" компоненте - то есть две смежных команды могут просто блокировать друг друга.

73 Чтобы максимально убрать эту проблему, необходимо наладить внутреннюю коммуникацию. В этом поможет наблюдаемость: в момент, когда работа одной команды приводит к проблемам у второй, все должны знать причину.

74 * Решением суда запрещена "деятельность компании Meta Platforms Inc. по реализации продуктов - социальных сетей Facebook* и Instagram* на территории Российской Федерации по основаниям осуществления экстремистской деятельности".

75 <a>Научитесь: Старт в DevOps: системное администрирование для начинающих Узнать больше</a>