Блог DevOps

Spark -- известный open source-фреймворк из экосистемы Hadoop-проектов, позволяющий выполнять распределенную обработку как неструктурированных, так и слабоструктурированных данных. Рассмотрим несколько фактов, которые стали причиной популярности фреймворка.

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

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

15 лет назад DevOps начинался в попытке “подружить” разработку и эксплутацию – через культуру, обмен знаниями и совместную работу. Затем быстро развернулся в сторону ускорения поставки изменений из разработки в продакшн (активность Lean Value Stream Mapping), продолжился в понимание того, что программисты создают не просто код в репозитории (и даже не протестированный код в репозитории), а работающее приложение в продакшне (практики Observability и SRE). И последние несколько лет DevOps перешел к рассмотрению взаимодействие команд на масштабе (фреймворк Team Topologies).

Большая ошибка многих рассуждающих в контексте DevOps о “снижении TTM” и необходимости “релизиться чаще” состоит в том, что они рассматривают частоту релизов и время “от коммита до продакшна” как технический показатель. В лучшем случае рассматривают с учетом простоев в цепочке поставке. Они считают, что если автоматизировать все, они смогут релизиться 100 раз в день и догонят и перегонят Google (конечно, для этого автоматизировать нужно “не просто так”, а “по-умному”).

Мы уже рассказывали о том, что DevOps в 1С есть, пусть и со своей спецификой. Давайте посмотрим, какие инструменты при этом используются, и как может выглядеть процесс в целом.

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

Kubewatch представляет собой инструмент с исходным кодом, предназначенный для мониторинга событий в Kubernetes. Он написан на Golang и способен отслеживать изменения во всех ресурсах кластера, уведомляя об этих изменениях посредством заранее выбранного канала либо веб-хука. Кроме того, инструмент поддерживает публикацию уведомлений на различных каналах, включая Slack, Hipchat, Flock, Webhook, Mattermost, SMTP.

Известная система "1С:Предприятие" довольно широко применяется для управленческого, складского, бухгалтерского и прочих видов учета на предприятиях. Кроме вышесказанного, она представляет собой еще и специализированную платформу для разработки ПО, используемого для автоматизации бизнес-процессов.

Можно сказать, что платформа "1С:Предприятие" -- это, по сути, своего рода образ среды для написания кода на собственном языке программирования, причем она же -- это еще и среда для выполнения написанного кода.

Поговорим о том, когда появился термин DataOps, а также в каком году он прочно вошел в лексикон специалистов по данным.