Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть1, Часть2, Часть 3, Часть 4. Сегодня мы обсудим совмещение нескольких подходов для управления сквозным бэклогом команды.

Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.

Всем привет! Меня зовут Максим, я работаю системным инженером в Yandex Cloud и в Яндекс Практикуме на курсе «Системный администратор». В этой статье я опишу свой субъективный взгляд на путь развития системного инженера (DevOps‑инженера, SRE, системного администратора).

Системный инженер — ключевой игрок в создании и поддержании сложных информационных систем. Он объединяет в себе знания из различных областей: от аппаратной части и инфраструктуры до программного обеспечения и сетей.

В дополнение к этой статье я создал:

- диаграмму на roadmap.sh;

- git‑репозиторий со ссылками на ресурсы для изучения (жду ваших пул‑реквестов).

В данной серии статей описан процесс создания первого pet-проекта для начинающего инженера в DevOps:

Глава 1: Введение и подготовка стенда

Глава 2: Настройка центра сертификации и репозитория

Глава 3: Настройка OpenVPN

Глава 4: Настройка мониторинга

В этой статье, подготовленной по мотивам моего доклада в «Школе мониторинга» Slurm, хочу поделиться своим набором best practice «Как лучше всего настроить Grafana Loki для сбора логов в инфраструктуре». 

На мой взгляд, порог входа в систему достаточно низкий, и в Интернете много туториалов. Поэтому я расскажу о более сложных и не совсем очевидных вещах, с которыми не раз сталкивался при работе с Grafana Loki. 

(Читать с толикой сарказма…) Все, кто работал с Ansible, знают, что он не хранит состояние результата своей работы. Это нелепое поведение Ansible, нельзя взять и просто удалить из git объекты конфигурации, чтобы они исчезли с управляемых систем, фу. При этом сразу вспоминается его величество Terraform с tfstate. Всех, кого раздражает подобное положение дел, прошу под кат.

Привет, Хабр! Я Виктор, техлид продукта CI/CD в Samokat.tech. А это, :(){ :|:& };: fork-бомба, которая создаёт свои дочерние процессы бесконечно. Запуск такой штуки в контейнере без ограничений роняет всю ноду. Не используйте в проде! Если запустить в WSL, то винду тоже укладывает. Как же избежать запуска такой штуки на проде? Помогут квоты.

Давайте разберемся как работают квоты в Kubernetes. Там есть немало граблей. В этой статье поделюсь своим опытом по работе с квотами – расскажу, чем квоты хороши, что у них под капотом, в каких задачах используются и почему нужны даже в среде single-tenant.

Привет, Хабр! Меня зовут Ахмед, я Deputy CTO в Сравни. 

Сегодня расскажу вам об опыте управления дежурствами в ИТ-команде.

Представьте: вы нашли баг на проде; хотите рассказать о находке коллегам, которые отвечают за эту функциональность. Идёте в рабочий мессенджер, пишете в канал или групповой чат соответствующей команды.

Linux продолжает быть одной из самых популярных операционных систем для серверов, облачных вычислений и IoT‑устройств. Знание команд позволяет эффективно управлять и настраивать эти системы.

Знание Linux может открыть двери к различным IT‑профессиям, таким как системный администратор, разработчик, инженер по безопасности и другие. Спрос на специалистов по Linux ожидается и в будущем.

В этой статье я собрал 12 советов по работе с Linux из собственной практики, которые помогут начинающим пользователям улучшить свои навыки в работе с этой мощной операционной системой.

Надеюсь, что эти трюки помогут вам стать более эффективным и уверенным пользователем Linux.

Все фишки я публикую в своем канале, где я публикую советы, инструменты и гайды для всех, кто работает с Linux и интересуется хакингом. А здесь я собрал папку полезных ресурсов.

Поехали!

Познакомил друга с понятием "Чистая архитектура" и он стал часто спрашивать меня как лучше сделать то или другое. Хотел дать ему к какому-нибудь туториал, но, к удивлению (плохому), не нашел подходящего.

Поэтому выкладываю небольшой обзор:

1.. Что такое чистая архитектура;
2.. Как можно реализовать;
3.. Мои мысли.

Всем привет, меня зовут Захаров Антон, и я DevOps-инженер в компании Bimeister! Весь свой опыт  я получил в этой компании, за 5 лет прошел путь от эникея до того, кем я работаю сейчас (большое спасибо коллегам!). Я расскажу, как на базе своих серверов и внутренних ресурсов мы создаем персональные стенды для разработки и тестирования нашего приложения.

Чем раньше команда задумается о проблеме безопасности, тем лучше. В этой статье обсудим, какие проблемы ИБ есть в стандартном контейнерном приложении, поговорим о безопасности использования Docker, Kubernetes и Terraform и разберём, как можно встроить проверки в стандартный пайплайн деплоя.

Материал написан и дополнен по мотивам выступления Любови Гринкевич и Алексея Миртова из Yandex Cloud на DevOpsConf. Он будет интересен DevOps-инженерам, специалистам по безопасности, владельцам продуктов и всем, кто хочет:

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

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

Позиция тимлида вообще предполагает relationship management, который может быть направлен как и на команду, так и наверх, в сторону стейкхолдеров. Но в этой статье я хочу поговорить именно про связку TL + Dev Team. Руководителю важно выстроить и поддерживать доверительные отношения с сотрудниками. Это поможет эффективно управлять командой и добиваться слаженной и продуктивной работы.

Если люди вам доверяют, вы будете получать более полную и достоверную информацию, сможете вовремя реагировать на проблемы, решать конфликты и строить долгосрочные планы.

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

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

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

Всем привет, меня зовут Зуев Алексей, и я работаю DevOps-инженером в компании Bimeister! Сегодня я расскажу вам о том, как мы облегчаем жизнь нашим разработчикам и как разработчик может отследить состояние своего микросервиса в namespace Kubernetes. Основная цель этой статьи - описать, как мы пришли к дашборду для персональных стендов разработчиков.

Речь пойдет о сборке, настройке и запуске охранной системы с датчиками, камерой, хранением видеозаписей на удаленном домашнем NAS, встроенным UPS, web-интерфейсом и оповещением через Telegram.

Чтобы быть предельно кратким, оформил статью в стилистике hackster.io. Информация рассчитана на читателей с опытом работы с одноплатным компьютером Raspberry и пониманием принципов работы VPN.

Я уже написал здесь много статей на тему прокси-протоколов и прокси-клиентов, которые очень сложно детектировать и заблокировать, и которые используют пользователи в Китае, Иране, Ираке, Туркменистане, и теперь вот в России (мы здесь в отличной компании, правда?). Но довольно часто мне в комментариях писали, мол, это все отлично, но мне нужен именно VPN для целей именно VPN - доступа в частные локальные сети, либо для соединения клиентов между собой, и желательно так, чтобы его не заблокировали обезьяны с гранатой. Поэтому сегодня мы поговорим именно о VPN.

Классические OpenVPN, Wireguard и IPSec отметаем сразу - их уже давно умеют блокировать и блокировали не раз. Модифицированный Wireguard от проекта Amnezia под названием AmneziaWG — отличная задумка, но есть одно но...

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

Во всём «виноват» terragrunt: каждому модулю terragrunt нужна отдельная джоба в пайплайне на plan и apply, но для каждого модуля они во многом повторяют друг друга. Подобное постоянное написание одинаковых частей CI/CD пайплайна при добавлении новых баз и бакетов навевало тоску.

Рассказываем, как мы создали генератор джоб в Gitlab CI/CD и навсегда забыли о ручном написании пайплайнов для развёртывания элементов инфраструктуры.