Привет! Меня зовут Лев, я руководитель интеграционной разработки в финансовом маркетплейсе Банки.ру.

Больше года назад мы начали переход на микросервисную архитектуру. Секретов становилось всё больше: пароли, токены, сертификаты, ключи. А управлять ими было всё сложнее. Количество команд давно перевалило за несколько десятков, а интеграций с партнерами, которые также защищены секретами, — за сотню.

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

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

Как бороться с типовыми причинами отказа? А самое главное — как их обнаружить? Рассмотрим лучшие элементы инженерной практики, обеспечивающие высокую доступность системы и оперативное расследование инцидентов. Коснёмся памяти, разберём базу данных, поговорим про ТСР-соединения.

Меня зовут Константин, я работаю в Газпромбанке. Занимаюсь транзакционными системами: платежами, переводами, также участвовал в разработке системы СБП в Газпромбанке. В своей практике столкнулся с десятками языков программирования, но в настоящий момент остановился на Java и Kotlin. Поэтому я буду рассказывать про проблемы backend разработки на этих языках.

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

Итак, проблема, которую мы будем решать — это смещение фокуса с развития на поддержку.

Всем привет меня зовут Максим, я SRE инженер в группе компаний Тинькофф.
И я продолжаю делать подборки видео с SRECon, которые показались мне интересными

Так вот, я просмотрел все доклады с SREcon24, составил для вас подборку из докладов, вырезав все доклады, в которых было больше болтовни или рекламы, чем пользы. Так же в этом году я добавил субъективный рейтинг для каждого видео.

Привет! На связи Олег Казаков из Spectr. 

В предыдущей части статьи я говорил о таком этапе DevSecOps как Commit-time Checks. Он отвечает за контроль корректности и безопасности кода в GIT-репозитории. А в этой части материала я расскажу, что же такое Post-build Checks, и как на этом этапе используется такой класс инструментов, как Container Cheсks.

Трудности в процессе разработки на Go — частая история. Чтобы их преодолеть, нам даже пришлось писать собственный бойлерплейт. Хотя казалось бы — всё уже есть, но нет, нам понадобилось имплементировать собственную хардкорную штуку. Расскажем, почему и зачем.

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

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

💬 На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно 🙂
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.

Как-то в конторе появилась мысль, что надо бы продумать как нам распараллелить работу над одни микриком, так чтобы команды не пересекались друг с другом. Есть некоторые API над которыми работают несколько команд. Каждая работает над своей фичей локально и пишет тесты, а вот при деплое на стэнд получается столпотворение потому, что нужно изменения слить в одну ветку аля develop и её закинуть на тест. При этом могут быть конфликты при мерже кода или измениться проперти, которые не совместимы между разными ветка.

Мобильный банк сейчас обслуживает 450+ микриков. Над которыми работают более 90 команд. Так как у нас в проекте нет code ownership, то каждая команда вносит изменения в нужные им микрики. Чтобы избежать различного рода сложностей, которые приводят к увеличению времени time to market, нужно было развести разработку отдельных команд так, чтобы они не влияли друг на друга и могли работать параллельно.

Ранее мы делали обзор инструментов для оценки безопасности кластера Kubernetes. Но что, если нам нужно обучить инженеров основам безопасности Kubernetes на реальных примерах и автоматизировать этот процесс? Недавно компания ControlPlane, специализирующаяся на Cloud Native-решениях, помогла решить этот вопрос. Она выложила в открытый доступ Simulator — инструмент для обучения инженеров поиску уязвимостей в Kubernetes. Мы во «Фланте» решили протестировать этот симулятор и понять, насколько он перспективен и полезен.

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

Стремительно растущая конфигурация K8s с современными трендовыми технологиями AI продолжает видоизменять трансформацию способов управления инфраструктурой и приложениями. В этой статье мы более детально обратимся к платформе K8sGPT, которая занимает центральное место в перевороте работы контейнерных приложений, начавшемся в 2023 году.

Хотя это и не новинка технологий, это не отменяет того факта, что она остается интересной темой для обсуждения.

В этой статье я хотела бы дать небольшое руководство по работе с cli, рассмотреть интересные фичи, а также представить возможные точки роста. 

Приятного прочтения!

Всем привет! Это снова Олег. Как и обещал, публикую вторую часть текста, посвященную вопросам, которые могут быть заданы на собеседовании по Kubernetes. 

Чтобы было понятно о чем речь, коротко: я работаю исполнительным директором по разработке в Газпромбанке, собеседую инженеров DevOps и системных администраторов. Делюсь вопросами (и ответами, конечно), которые могут быть заданы на собеседовании. Первую часть можно найти здесь. Итак, поехали.

Современный мир бизнеса и разработки программного обеспечения характеризуется высокой динамикой и необходимостью быстрого реагирования на изменения в рыночных условиях. В этом контексте эффективная организация команд становится ключевым фактором успеха. 

Team Topologies - это концепция, которая предлагает рациональный и гибкий подход к организации команд внутри организации. Классические подходы к организации Agile команд, как правило, рекомендуют создавать универсальные и кроссфункциональные команды, где любая команда может сделать любую фичу из беклога.

Всем привет! На связи Сергей Гончарук, менеджер проектов компании «Флант». 30 ноября и 1 декабря 2023 года прошла конференция TeamLead++ Conf 2023. Ниже — текстовый вариант моего доклада с конференции про опыт «Фланта» в построении процессов управления задачами для Dev-части нашей DevOps-работы. 

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

Всем привет! Меня зовут Максим, я релиз-инженер Ozon, и в этой статье я расскажу про впихивание невпихуемого, или про оптимальную с точки зрения используемых ресурсов стратегию деплоя в Kubernetes, которая позволила нам сэкономить тысячи ядер CPU и терабайты RAM.

Я довольно долго прожил в Сиэтле и Калифорнии, и один из первых вопросов, который мне всегда задают: как там, в стране американской мечты? Я всегда отвечаю — это зависит. Пока что этот ответ никого не удовлетворил…

Очевидно, этот вопрос часто задаётся не из пустого любопытства, особенно если я разговариваю с человеком из IT. Многие технические специалисты думают о том, чтобы испытать удачу в США.

Итак, как там на самом деле? Мы видели много разных публичных мнений, от очень хайпового фильма «Кремниевая Долина» Юрия Дудя, изображающего идиллический и солнечный образ, до очень негативного от Артемия Лебедева.

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

Давайте посмотрим что есть что.

С момента публикации концепции Twelve-Factor App значительно изменилось то, как мы создаём, упаковываем и развёртываем приложения. Контейнеры, Kubernetes и облачные технологии стали основными технологиями, которые позволяют нам создавать переносимые, масштабируемые и надёжные приложения. Тем не менее 12 факторов, сформулированных в концепции, всё ещё актуальны в современном технологическом стеке.

Перевели статью, в которой описывается методология Twelve-Factor App и применение её концепций в контексте контейнеров и Kubernetes.

Привет, Хабр! Меня зовут Даниэла, я руковожу направлением корпоративных льгот в Росбанке. В этом посте я расскажу, что такое выгорание, как оно проходит, как уберечь себя от выгорания, отслеживать его у сотрудников и, наконец, что мы для этого делаем в компании.