Классное видео о #devops

https://www.youtube.com/watch?v=nrr4IwOVhZk

Контрольный список для DevOps и инженеров, обеспечивающих бесперебойную работу систем. #devops. Евгений Зятев
https://zyatev.ru/devops/kontrolnyi-spisok-dlia-devops-i-inzhenerov-obespechivaiushchikh-bespereboinuiu-rabotu-sistem

В продолжении предыдущей ссылки что касается базовых знаний для #devops, ну чтобы начать отвечать на вакансии на HR-сайтах для себя нашел список из одной вакансии компании fevlake. По мне лаконично и по делу.При веду ее тут:
🔸 HTTP/HTTPS: как работает, как посмотреть хедеры в ответе, как работает SNI, как получить страничку telnet'ом
🔸 DNS - знать и понимать зачем нужен TTL, как работает рекурсивный поиск, как отдавать разные ответы в разные Geo зоны
🔸 Linux - важно уметь работать с Bash, уметь писать скрипты, использовать общие системные инструменты для анализа проблем
🔸 Monitoring - миниум Zabbix + любая time series база (Graphite, Prometheus, InfluxDB, etc...) , уметь писать скрипты для мониторинга (Python/Golang/Bash/...)
🔸 nginx - как работают locations, как настроить HTTPS, как кастомно редиректить различные запросы, как жить с QPS 10k
🔸 Configuration Management - как быстро развернуть и настроить 100 серверов и запустить их в продакшн (Ansible)
🔸 Jenkins/GitLab CI - уметь настраивать билд таски, подключать билд агентов, разбираться в билд логах и читать ошибки
🔸 Docker - как написать Dockerfile, как собрать образ, как задеплоить собранный образ на staging/production сервер
🔸 Databases (MySQL/PostgreSQL) - как минимум уметь писать простые sql запросы, анализировать вывод, уметь пользоваться командами explain, понимать для чего нужны индексы
🔸 Logs management - знать, что такое ELK stack, что значит каждая буква из этой абревиатуры и как это все настраивать
🔸 Git - знать, что такое репозиторий, как его склонировать, запушить и почему git push --force вызывает злобу у людей вокруг
🔸 Let's Encrypt - знать, как настроить с web proxy
🔸 Container orchestration - Kubernetes
🔸 AWS / Google Cloud - на уровне создать пользователя, загрузить файлики, добавить A запись

Любопытная статья на тему ценности devops для бизнеса. Перечислены метрики, которые позволяют оценить, как компания использует DevOps и какова роль инженера в их улучшении.
Это такие метрики как:
🔹Частота деплоев (deployment frequency) — как часто вы деплоите код в продакшен или как часто ваши конечные пользователи получают новые релизы.
🔹Время внесения изменений (lead time for changes) — от коммита кода в репозиторий до его выкладки в продакшен.
🔹Время за которое сервис восстанавливается после сбоя или аварии (time to restore).
🔹Частота аварий, вызванных выкладкой изменений (change failure rate) — какой процент деплоев приводит к ухудшению качества обслуживания пользователей и требует исправлений, например, откатов.
А как у вас состояние данных метрик? Нужен вам #devops?
https://habr.com/ru/company/itsumma/blog/525070/

Как Васян собеседует ☺️

#devops
https://habr.com/ru/company/rebrainme/blog/527782/

Бесплатный интерактивный инструмент, созданный сообществом DevOps в котором собраны наиболее популярные инструменты
#devops
https://digital.ai/periodic-table-of-devops-tools

Сделал публикацию на хабре.
Перевод статьи ребят из Netflix. Как они внедряли DevOps для Windows. Статья достаточно обзорная, но если необходимо реализовать, дается направление в том, какие инструменты использовать.
Сам используя Chocolatey как менеджер пакетов для Windows.
#devops
https://habr.com/ru/post/536638/

Наткнулся на тест: Какой из вас выйдет девопс-инженер?
Скриншотим сюда результат.
#devops
https://nplus1.ru/material/2020/10/12/sm2

Известный ADV-IT на своем канале опубликовал видео о инструментах на своем компе, которыми он пользуется как DevOps.
https://www.youtube.com/watch?v=aQlG-c3_z5E
Можно взять на заметку.
На этом фоне решил описать и свои.
Что касается OS на компе, у меня на самом деле несколько машинок:
1 десктоп как основное рабочее место дома: Ubuntu 18.04 (Kde Plasma)
2 десктоп как основное рабочее место в офисе: Windows 10 Pro (достаточное количество windows-клиентов и серверов (например AD) поэтому удобнее иметь ту же платформу)
Железо думаю не так интересно - не топовое. А вот два монитора обязательно - прям сейчас не могу без этого.
3 - ноутбук (если вне офиса (дома) или полежать-поработать на диване: старенький Macbook Air
Сознательно сделал выбор в пользу такого разнообразия. С одной стороны это знание всего многообразия ОС и их возможностей (когда-нибудь все таки сделаю выбор в пользу одной), с другой стороны так оказалось сложнее, потому что в разных системах - разные инструменты.
Может меня и запинают сейчас, но по удобству расставлю приоритеты в таком порядке: Windows (нравится UI), Ubuntu (именно KDE) (для devopsa самое то, потому что многие вещи работают без прослоек (привет, docker)), Mac.
На серверах раньше старался держать CentOS, сейчас больше склоняюсь к Debian (привет. Proxmox), посмотрим чем закончится эпопея с центиком.
Для возможности работы на других ОС использую VirtualBox, часто в связке с Vagrant. Ну или облако - если не надолго.
Инструменты для удалённого подключения к серверам зависят от OS. К сожалению найти что то кроссплатформенное не удалось, не считая конечно просто команд ssh в консоли и других нативных клиентов. Ну есть Filezilla для scp и ftp под все платформы.
В Ubuntu использую Asbru Connection Manager (прям понравился - рекомендую попробывать) и Remmina для rdp.
В Windows - это mRemoteNG для всего (тоже нравится).
В Mac - Termius для ssh (не нашел что-то, такое же удобное для mac, как инструменты выше), для rdp - родной клиент.
Код пишу в Visual Studio Code - благо он кроссплатформенный. Прицепил кучу плагинов - удобно.
С API работаю редко. Спасибо за наводку поставил Postman.
Из браузеров предпочитаю Chrome и Firefox.
Из VPN - OpenVPN с его нативными клиентами, под Mac - tunnelblick.
Приходится часто работать с PostgreSQL: psql самый предпочитаемый, а удаленно - PgAdmin. Для Mysql - mysqladmin и PhpMyAdmin.
Что еще хотелось отметить из инструментов:
Для написания документации: красивые графики и схемы: draw.io - есть десктоп-клиент, Word и Excel от LibreOffice, Сonfluence как wiki, git для IaC.
Накидайте в комметах свои тулы, может что то упустил или посоветуете?
А вообще, если у вас есть свой канал, как насчет челленджа #комп_devopsа_инструменты ?

#devops.com

Нравится смотреть видео про чужой опыт, инфраструктуру в другой компании. Вот одно видео месячной давности с митапа в Инополлисе про Магнит. Если интересует DevOps часть то нужно смотреть с 1:43:02. Не скажу что сильно познавательно. Достаточно традиционный стек технологий. Но может кому-то пригодится.
#devops #магнит
https://www.youtube.com/watch?v=ti9sNhGvx8A

Практическая история про то, как ребята внедрили DevOps у себя на небольшом проекте в Ispring без Docker и Kubernetes на продакшене.

#devops

https://www.youtube.com/watch?v=nr1883za8tM&t=12844s

Начать хотел не по-порядку, а с практики проектирования приложения для использования DevOps -подхода.
Что в него входит:
• Приложение спроектировано так, чтобы поддерживать модульную независимую сборку, тестирование и релизы. Другими словами, сам продукт разбит на модули с минимальными зависимостями между ними. Таким образом, модули могут быть построены, протестированы и выпущены без необходимости одновременной сборки, тестирования и выпуска всего продукта.
• Приложения спроектированы как модульные неизменяемые микросервисы, готовые к развертыванию в облачных инфраструктурах в соответствии с принципами 12-факторов приложений, а не на основе монолитной, изменяемой архитектуры.
• Изменения исходного кода программного обеспечения перед слиянием в общую ветку предварительно:
1. проверяются с помощью инструментов статического анализа. Инструменты статического анализа используются, чтобы гарантировать, что новый код не приводит к критическим программным сбоям, таким как утечки памяти, неинициализированные переменные и проблемы с границами массива.
2. проходят код-реью.
3. проверяются тестами динамического анализа, чтобы гарантировать, что производительность программного обеспечения не снизилась.
4. проверяются тестами функционального тестирования.
• Программные фичи помечаются тегами во время коммита для обеспечения возможности выборочного функционального тестирования и отката.
• Результаты автоматизированного тестирования регистрируются в сливаемой ветке вместе с подтверждением того, что тесты прошли в тестовой среде.
• Разработчики коммитят свой код регулярно, не реже одного раза в день.

Продолжение следует ...
#devops

Был на той неделе онлайн на DevOpsConf. Было достаточно много интересных докладов. Законспектировал парочку. Возможно выложу интересные моменты. А пока хотел рассказать про один доклад по теме, в которой давно хотел разобраться. Это "Контроль защищенности внешних зависимостей в коде". Ведь все мы в той или иной мере при разработке и даже в инфраструктуре используем чужой код.
Как обычно люди хранят зависимости:
- Не используют зависимости
- Хранят в виде готовых артефактов в репозитории вместе в основным кодом
- Копируют код и хранят в своем репозитории
- Хранят в виде списка зависимостей и выкачивают при необходимости. Последний пункт наверное самый популярный.
Основная проблема использования - это вопрос информационной безопасности (заведомо злонамеренный компонент, ошибки при кодировании библиотеки, перехват управления/эксплуатация доверия библиотеки, целенаправленная атака на внутренние компоненты, вредоносная активность в установочных скриптах, проблемы с зависимостями зависимостей) и проблема прекращения поддержки (вплоть до того что код уже не откуда взять).
Как сделать правильно:
- Использовать только внутренний репозиторий зависимостей - прокси, например Nexus. В платной версии вроде ещё и умеет искать "недостатки".
- Фиксировать версии зависимостей
- Сделать анализ кода самим, но это очень долго и трудоемко. Решение - поискать публичную информацию об уязвимостях (эксплойтах) - Например в cve.mitre.org или использовать Dependency-check (https://github.com/jeremylong/DependencyCheck ).
Майкрософт выпустил рекомендации для тех кто использует зависимости в виде чужого кода:
https://azure.microsoft.com/mediahandler/files/resourcefiles/3-ways-to-mitigate-risk-using-private-package-feeds/3%20Ways%20to%20Mitigate%20Risk%20When%20Using%20Private%20Package%20Feeds%20-%20v1.0.pdf

Пару слайдов в комментариях
#devops #зависимости

Хотел с вами поделится одним проектом (назовем его так) - это DevOps Kitchen Talks☕️. Ребята (из Минска) собираются каждую неделю и обсуждают DevOps- новости, статьи, тренды в неформальной обстановке. Сам их смотрю в Youtube. Болтают долго - часа 2 (рекомендую включать х2😁), но есть тайминги и дают ссылки на то что обсуждают.
Кстати в последнем выпуске обсуждали статью на которую я давал ссылку в посте выше про то как живется ДевОпс 🖕🏻

#devops #рекомендую
https://www.youtube.com/watch?v=W5mZSBK5MrE&t=3277s

Размышления коллеги по итогу участия в DevOpsConf

Я писал выше о двух докладах с этой конференции:
https://t.me/orangedevops/170
https://t.me/orangedevops/183

Из того что понравилось в статье это сравнение ITIL c SRE и золотой середине между ними:

🔹"Если рассматривать SRE и ITIL как два разных подхода к автоматизации, то оказывается, что ITIL требует автоматизировать рутину, а SRE считает, что нужно автоматизировать вообще все"
🔹"SRE говорит о том, что у нас есть Chaos Engineering, где, если утрировать, мы рандомно отключаем сервера из сети в production, отслеживаем реакцию систем на отключения и анализируем, как изменить систему таким образом, чтобы она выдерживала подобные отказы.
ITIL же считает, что на все случаи жизни есть Disaster Recovery Plan, в котором описываются все необходимые действия при возникновении аварии."

И цитата которой я стараюсь придерживаться:
🔹"если нужно сделать систему надежной, то из нее скорее нужно что-то убрать, нежели добавить. Системы нужно делать проще."

#devops

https://habr.com/ru/company/mvideo/blog/579818/

Три истории про бездумное применение инструментов. Возможно - погоня за хайпом. Но в итоге они не только не решали проблемы, но создавали новые.
В общем надо сначала понять решает ли инструмент конкретные задачи проекта и все ли члены команды понимают зачем он и пользуются им
#devops
https://habr.com/ru/company/luxoft/blog/584798/

∞ 11 лучших каналов YouTube, посвященных DevOps

#devops
https://proglib.io/p/11-luchshih-kanalov-youtube-posvyashchennyh-devops-2021-11-08

Вдогонку ещё и книги:

#книга #devops
https://proglib.io/p/top-10-knig-iz-biblioteki-specialista-devops-2020-09-29

Сборник awesome на github полезных devops:
#linux: Awesome-Linux-Software
#devops: awesome-devops
#sysadmin: awesome-sysadmin
#nginx: awesome-nginx
#kubernetes: awesome-kubernetes
#docker: awesome-docker
#aws: awesome-aws
#googlecloud: awesome-google-cloud
#иб: awesome-security