DevOps *

Долгие годы люди стремились к всё более реалистичному изображению окружающих их вещей. Много лет прошло от симпатичных наскальных мамонтов до шедевров эпохи Ренессанса и Просвещения. Однако где-то в 19-м веке (примерно, когда стала появляться первая фототехника, ага), что-то пошло не так, и живопись сменила своё направление от реализма к абстракции. Дальше больше; и все "скатилось" до клякс, пятен и потёков, размазанных по холсту или любой другой поверхности стоимостью в миллионы долларов... И при этом зачастую совершенно было непонятно, кто автор "шедевра": 3-х летний ребенок, маститый художник, нейросеть или кот, опрокинувший банку варенья.

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

В этом посте мы рассмотрим основные моменты генерации данных с нуля (на основе схемы БД), а так же на основе уже существующих данных. Рассмотрим способы, методы, особенности и инструменты. А каждый шаг будем иллюстрировать примерами живых и настоящих SQL-запросов (в основном PostgreSQL-flavour, но постараемся и не только). И в итоге убедимся, что SQL позволяет нам не только эффективно работать с уже существующими данными (на минуточку, уже почти на протяжении 50 лет), но с помощью него их можно еще и довольно эффектно придумывать.

Привет Хабр сегодня мы поработаем с Azure Monitor Activity Logs в три простых шага: логгинг, мониторинг и алертинг.

Продолжаем делиться конспектами Алексея Барабанова, IT-директора «Хлебницы». На этот раз обсудим специфику работы RabbitMQ с высокими нагрузками (High Load) и обеспечением высокой доступности (High Availability). Рассмотрим различные методы увеличения производительности и горизонтального масштабирования, разберём и настроим внутренние инструменты. Также по мере погружения постараемся изучить основные подводные камни всех подходов.

В составе Kubernetes-платформы Deckhouse появился новый модуль delivery, в основе которого — утилита с открытым исходным кодом Argo CD. Модуль автоматизирует процессы непрерывной доставки, развертывания и обновления пользовательских приложений в кластере. Также, благодаря доработке «ванильной» версии Argo CD, delivery повышает удобство доставки ПО в закрытые контуры при помощи werf.

На прошлой неделе Meta объявила о еще 10 000 предстоящих сокращениях. Конечно, увольнения ужасны, но есть несколько интересных моментов. Прежде всего то, что они явно сокращают, порой, перенасыщенную структуру компании:

Виртуальные серверы VPS в Нидерландах

Перевели статью о создании пайплайна для развертывания статического веб-сайта на AWS S3 Bucket на примере Gitlab CI/CD, чтобы быстро вникнуть в основы технологии и начать применять ее в работе. В статье рассматриваются базовые концепции CI и CD, а также этапы CI/CD-пайплайна.

Привет, меня зовут Сергей — я руководитель DevOps-направления KTS. 

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

В этой части расскажем, как программисты работали раньше.

Введение

У меня была задача «Собирать статистику постов в vk каждый час». Я не являюсь разработчиком или DevOps специалистом. Поэтому мой способ решения задачи сложился из поисковых запросов, личного опыта, советов друзей и коллег.

Решение я разбил на 2 части.

Это небольшой гайд о том, как обеспечить наблюдаемость в вашей событийно-ориентированной облачной системе.

В период с 199x по 201x развелось очень много программистов-микроконтроллеров, которые никогда не представляли свою работу без IDE (IAR, KEIL, Code Composer Studio, AtilocTrueStudio).

В этом тексте я написал про недостатки работы в IDE и альтернативный способ сборки и масштабирования кодовой базы. Про MakeFile(ы).

Нужен ли каждому разработчику свой dev-сервер? Многие компании, опасаясь лишних расходов и проблем, даже не пробуют внедрить такой подход.

CarPrice развернул свои dev-серверы еще в те далекие времена, когда все работало на монолите. А после монолита пилил собственный сервис для оркестрации dev-серверов на базе Docker, затем разворачивал их на Minikube и постепенно пришел к Kubernetes.

На связи ведущий инженер отдела DevOps CarPrice Михаил Чешуин. В этой статье я расскажу, как мы запускали dev-серверы в разные периоды — и как все работает сейчас

В этой статье мы поговорим об использовании Chaos Mesh — опенсорс-фреймворка для хаос-инжиниринга в Kubernetes. Все развёртывания из этой статьи доступны на GitLab. Клонируйте репозиторий и продолжайте читать.

Для разработчиков построение масштабируемых и поддерживаемых приложений может быть значительным вызовом, особенно при работе с большими кодовыми базами и несколькими сервисами. К счастью, использование подхода монорепозитория в сочетании с мощными инструментами, такими как NX, Lerna и Yarn, может обеспечить упрощенный процесс разработки, который повышает общность кода и возможность повторного использования.

Это подробное руководство нацелено на помощь разработчикам в настройке монорепозитория с использованием NX, Lerna и Yarn. Руководство включает подробную информацию о начальной настройке, структуре каталогов, управлении зависимостями, тестировании и развёртывании.

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

На протяжении более чем 10 лет работы с PostgreSQL, периодически наблюдаю, как команды на начальном этапе, зачастую, не уделяют внимание ролевой модели базы, или как вся команда работает под суперпользователем postgres и забывает про версионирование схемы.

В процессе общения с различными командами в НЛМК у меня появилась идея предложить им «преднастроенный PostgreSQL». Как в итоге сделали — под катом.

Привет Хабр! Не так давно общался с SRE в нашей команде и он рассказал мне о базовых принципах процесса управления инцидентами, теперь я поделюсь этим с вами, быть может кому‑то поможет.

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

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

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

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

Вас приветствуют Гевонд Асадян и Илья Мясников. В банке «Открытие» в управлении риск-технологий мы занимаемся внедрением моделей оценки кредитного риска. В этой статье на примере большого и сложного процесса выдачи экспресс-кредитов мы расскажем, как нам удалось реализовать полноценный дубль процесса на стороне одного проверочного скрипта и ускорить процесс выдачи экспресс-кредитов с двух рабочих дней до семи минут.

Не всякий девелопер долетит до PROD, что конечно, правильно, и более того, в ряде случаев регулируется законами разных стран (персональные данные, кредитные карты итд). Однако для эффективного функционирования важны не только, скажем так, восходящие потоки (деплой DEV → QA → PROD), но и нисходящие, существующие в виде предоставления девелоперам очищенных баз для тестирования, метрик с PROD, логов, сообщений об ошибках, и, в худшем случае (проблема существует и воспроизводится только на PROD) доступе разработчиков на PROD.

Лирическое отступление. С детства мне в память врезались (видимо из журнала «Наука и Жизнь») шкалы землетрясений и ветра. Интересно двигаться по баллам ветра плавно переходя от «ветер едва колышет листья» до «ветер с корнем вырывает деревья». Давайте и мы составим такую шкалу для уровней сложности попадания на production — с примерами и рассказами из жизни.

Рассказываем, как благодаря использованию некоторых специальных технологий Linux, включая пространства имён и группы управления, появились контейнеры.