В серии статей по теме DevOps мы вместе с Lead DevOps инженером департамента информационных систем ИТМО Михаилом Рыбкиным рассказываем о проверенных инструментах выстраивания инфраструктуры, которыми с недавнего времени пользуемся сами. В предыдущих статьях мы уже рассмотрели предпосылки перехода на новую инфраструктуру, познакомились с азами Kubernetes и обсудили методы доставки кода. В рамках последней темы мы пришли к методологии GitOps, при которой конфигурация кластера описана декларативно и есть ровно один источник правды ― git с его историей версий и т. д. Но git не является достаточно доверенной средой для хранения секретов ― с его помощью мы не смогли бы обеспечить разделение доступов и т. п. Так что в следующей статье цикла мы рассказываем о том, как можно реализовать отдельное хранилище секретов, без которого полноценно перейти на GitOps невозможно.

Если у вас есть продукт, то у вас есть обязательства перед конечными пользователями. В этом случае SLA (соглашение об уровне обслуживания) — это отличный инструмент. Он помогает сфокусировать внимание разработчиков продукта на том, что больше всего нужно вашим клиентам.

Перевели статью, автор который делится практическими советами при создании SLA. Они помогут лучше понять эту задачу. Автор касается вопросов: что измерять, как измерять где и, самое главное, какие целевые пороги установить.

Приветствую, коллеги.

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

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

Итак, представим, что у нас имеется некоторое количество приложений, которые изначально “не обучены” отдавать аналитику в режиме реального времени. Задача заключается в том, чтобы построить систему мониторинга бизнес-показателей с минимальным вмешательством в эти системы.

Существует множество способов решить эту задачу, и как водится, все они обладают своими достоинствами и недостатками. Основное достоинство описываемого способа заключается в очень простой реализации на стороне приложения (с которого есть необходимость получать аналитику). Но если бы мы сейчас разрабатывали все те приложения, которые нужно “научить” делиться аналитикой, то мы бы, наверное, их подружили с брокером сообщений типа Kafka или Rabbit, а внедрять в уже существующие приложения работу с брокером сообщений (особенно, если брокеры очередей сообщений не развернуты в компании) значительно сложнее, чем просто научить приложения писать свои показатели в лог.

Итак, рассмотрим подробно, как устроена предлагаемая система:

В основе системы лежат события, которые генерируют приложения. События сохраняются в лог (stdout, файл,..). Обработчик (сборщик) логов (в режиме реального времени) распознает в логах события приложений и отправляет их в хранилище (БД).

Казалось бы простая задача - переместить логи из пункта А в пункт Б, что тут сложного. Но даже для такой пустяковой задачи придумали множество ПО: как более популярных Rsyslog, Logstash, fluentd, fluentbit, так и менее известных как file.d, недавно принудительно-опенсорснутая Пилорама (спасибо, Яндекс!).

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

Привет, Хабр.

В одном из проектов, связанных с мониторингом, мы используем Clickhouse, Prometheus, VictoriaMetrics, Grafana, Alertmanager и Vector.dev. Кстати, что общего у всех этих компонентов? Они написаны не на Java – это было одним из требований проекта, но речь ниже пойдет не об этом, а о Vector.dev.

Хорошая статья про Vector.dev есть на Хабре – но мы решили проверить свою карму, затащив Vector.dev в PoC. На текущий момент полет вполне нормальный: используем ограниченное количество source и sink’ов: File, Clickhouse, HTTP, JournalD и, конечно, сам Vector и его логи (немного погоняли kubernetes_logs, кстати, интересный доклад по теме логов Kubernetes был на недавней VK Kubernetes Conf’23).

Оффтоп

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

Про работу на нескольких проектах

Многозадачность в тренде, но еще не у нас
Кто может?
А эффективно?
Сколько брать?
Принципы и рекомендации

По личному опыту удаленки в  малом бизнесе

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

Кому будет полезна статья?

• аналитикам и их руководителям, которые устали от бесконечного потока ad-hoc задач и хотят построить нормальный процесс работы;

• продактам, которые устали от того, что бизнес-заказчики двигают свои задачи вперед и нарушают планы продуктовой команды;

• бизнес-заказчикам, которые недовольны скоростью решения задач и отсутствием прозрачности в процессе их решения.

Автоматизация развертывания стенда Kubernetes

Что бывает когда стандартное и самое распространённое решение по изучению kubernetes по каким то причинам даёт осечку на твоей рабочей машине?

Ты начинаешь пилить свой велосипед конечно! Вот и я напилил. и он даже катается!)

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

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

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

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

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

В этом посте описан мой топ-25 обязательных инструментов CLI, на которые я привык полагаться. Если тут нет вашего любимого - дайте мне знать в комментариях :)

Рассказываем, как использовать Jenkins CI/CD Pipeline для создания инфраструктуры AWS с помощью Terraform и Ansible. Мы не будем вдаваться в подробности, как настраивать Terraform или тестировать код по мере создания инфраструктуры, так как эти шаги считаются стандартными. Конечный результат — код Terraform, создающий среду AWS с общедоступными подсетями и инстансами EC2 с Ansible Playbook. Когда код помещается в репозиторий GitHub, GitHub Webhook запускает Jenkins CI/CD Pipeline, действия которого зависят от того, куда мы отправляем код — в ветку разработки или основную.

Привет, друзья!

Представляю вашему вниманию перевод этой замечательной статьи, в которой рассказывается о Miller — автономном, легковесном и мощном интерфейсе командной строки (Command Line Interface, CLI) для работы с данными в форматах CSV, JSON и некоторых других.

Интересно? Тогда прошу под кат.