DevOps *

SRE объединяет группы разработчиков программного обеспечения и инженеров эксплуатации и помогает создавать надежные, отказоустойчивые и масштабируемые системы. Некоторые из преимуществ этой методологии:

• Улучшаются коммуникации в команде

• Совершенствуется культура

• Уменьшается доля ручного труда

• Клиенты чаще остаются довольны

В современном мире бизнес и технологии постоянно развиваются и адаптируются к потребностям рынка. Одним из таких трендов является использование low-code и no-code платформ в разработке программного обеспечения и бизнесе. Сегодня Low-code и no-code платформы предоставляют возможность быстрого создания и автоматизации бизнес-процессов с помощью графических интерфейсов и предустановленных инструментов. Это позволяет бизнесу ускорить разработку продуктов, сократить расходы и получить более качественный результат, при этом не требуя глубоких знаний программирования. Также эти решения могут использоваться разработчиками в качестве дополнения к кастомным проектам, путем интеграции готовых компонентов для ускорения процесса разработки и оптимизации работы над проектом. Вместе с экспертами мы обсудили различные аспекты low-code и no-code решений, их влияние на рынок разработки программного обеспечения, а также затронули реальные примеры успешного применения таких платформ в сфере бизнеса и разработки.

О чем и для кого статья

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

Я подразумеваю, что читатель статьи уже владеет основами Terraform.

Предполсылки и требования

Для начала хотелось бы рассказать о нашей компании. Мы финтех стартап, занимающийся факторингом. Мы с самого начала развивались как cloud native. Все наши вычислительные мощности и сервера находятся в Azure.  

На момент событий, описываемых в статье, большинство наших ресурсов составляли Azure App Service, Azure Sql Servers и Azure Blob storages. У нас было два крупных монолита и около 10 микросервисов вокруг. Честно говоря, это было больше похоже на распределённый монолит, потому что тестировать приходилось всю экосистему, а не отдельные сервисы.

В определенный момент мы начали очень быстро расти с, примерно, 20 человек в Tech отделе до 120 за год. В это время основной нашей болью было количество тестовых сред. У нас были три среды: test, staging и prod. Команды толкались в этих средах, test был постоянно разломан, протестировать что-либо было невозможно. От этого staging тоже забивался неработающим функционалом и выпуски затягивались на недели. 

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

Код Terraform является декларативным. Мы используем его, чтобы определить, что мы хотим получить от наших облачных провайдеров. Если перевести этот код на простой язык, то он будет выглядеть как подробный список покупок:

Дай мне частную виртуальную сеть с базой данных и кластером kubernetes. Кластер должен иметь некоторое количество узлов, и все они должны использовать определенный тип CPU. База данных должна быть расположена именно здесь, и она должна иметь возможность хранить определенное количество гигабайт…

Цель этой статьи — рассказать о том, как мы в Bulder Bank подходим к проблеме написания понятного кода Terraform.

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

В мире IT тоже периодически происходят «катастрофы»: от перегоревшего жёсткого диска на личном ноутбуке до пожара в ЦОДе, хранящем данные миллионов пользователей. Проводя параллель, можно сказать, что IT-компании во многом схожи с городами, они тоже активно занимаются снижением рисков, оценкой, реагированием и ликвидацией последствий так называемых инцидентов — «катастроф» на языке IT.

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

Логирование — один из трех столпов observability в распределенных системах. Мы видим, как растут популярные продукты с открытым исходным кодом (например, ELK-стек) и зрелые коммерческие продукты (например, Splunk) для ведения логирования в больших масштабах. Однако в такой сложной системе, как Kubernetes, логирование остается серьезной проблемой. Она усугубляется с ростом данных и широким внедрением контейнерной системы.

В этой статье мы рассмотрим различные типы логов Kubernetes, необходимые для observability, а также подходы к сбору, объединению и анализу этих логов в Kubernetes. Затем мы представим решение с открытым исходным кодом, использующее fluentd и fluentbit, чтобы упростить ведение логов. 

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

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

Приветствую! Меня зовут Евгений, я DevOps в команде развития инфраструктуры. Мои прошлые статьи были посвящены протоколу BGP, но в этот раз я приготовил нечто поинтереснее. В прошлом году мне захотелось расширить своё портфолио навыков в сторону автоматизации задач. Не последнюю роль в этом желании сыграла книга «Автоматизация программируемых сетей», выпущенная известным в IT-кругах издательским домом O'Reilly. В ней примеры скриптов написаны на Python. Позже я в учебном центре прошёл курс повышения квалификации по программе «Python для сетевых инженеров. Автоматизация сетевых задач», а затем продолжил самостоятельно постигать это искусство. Недавно подвернулась интересная задача, о решении которой при помощи Python я вам сегодня и расскажу. Усаживаетесь поудобнее, мы отправляемся.

Всем привет! Снова на связи General RJ45 с новым прекрасным решением, но на сей раз по теме ML и аналитики.

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

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

Стек того что мы поднимем в рамках этой статьи, также будут и другие инструменты как Nginx, Postgresql но мы их учитываем как часть компонентов ниже:

Как крутить 2 сервера с белыми IP одного компа, и попутно разрабатывать Telegram Web Apps  на Bot API 6.7. Фронт + бэк на примере веб приложения внутри телеграм React + Fast-api.

Нам говорят, что Apache Kafka сохраняет порядок сообщений для каждой темы/раздела, но насколько это правда? В этой статье мы проанализируем несколько реальных сценариев, в которых слепое принятие этой догмы, может привести к неожиданным и ошибочным последовательностям сообщений.

В мае 2023 года «Фланту» исполнилось 15 лет. За это время из небольшого предприятия двух друзей-студентов, которые мечтали поставить GNU/Linux на каждый рабочий стол, мы выросли в команду опытных и уважаемых в индустрии DevOps-инженеров и постепенно трансформируемся в продуктовую компанию с собственной экосистемой продуктов.

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

Сразу обозначим свой «символ веры». Услуга DevOps as a Service (DaaS) была, есть и будет основой нашей продуктовой линейки. Именно благодаря инженерам, которые 24/7 обслуживают сотни клиентских кластеров, мы можем получать максимально быстрый фидбэк по своим продуктам, тестировать новые релизы и собирать кучу новых идей для дорожной карты. То есть в нашем случае услуга, как бы странно для классических продуктовых компаний это ни звучало, является одним из ключевых компонентов продуктовой разработки.

Привет! 

Меня зовут Александр Маркачев, я 3,5 года работаю на позиции Data Engineer в билайне и люблю открывать для себя что-то новое и интересное в работе. Так случилось и с темой, которой я сегодня хочу с вами поделиться — со spill-ами.

Под катом мы поговорим о том, что такое Spill-ы в контексте Spark, и почему именно для Spark это не такая уж сильно плохая штука. Рассмотрим, из-за чего Spill-ы в принципе возникают, разберем несколько видов Spill-ов (и даже вызовем их намеренно), а затем будем решать эту проблему.

Что такое spill-ы в Spark

Вообще, Spill — это термин для обозначения процесса перемещения данных из памяти на диск, а затем снова обратно в память. По крайней мере, именно так гласит официальная трактовка. Если проще, то дело вот в чем — когда у Spark не хватает ресурсов для обработки, он перемещает данные на диск.

В процессе обработки существуют разные участки — есть Executor Memory, есть Storage Memory, и когда эти участки оба целиком заполнены, то они начинают переполняться и вызывать утечку данных. Причем в отличие от утечки в C, Java или еще где-то, в Spark это преднамеренное действие для того, чтобы ваша задача не падала. Собственно, именно поэтому при нехватке ресурсов данные и «проливаются».

Можно ещё сильнее упростить аналогию.

Эффективность – как часто в своей жизни мы слышим это слово. Эффективность бывает самая разная и обычно под ней подразумевают улучшение тех или иных бизнес-процессов.

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

Я - Антон Будкевич, глава разработки IT-решений НСПК Мир Plat.Form, и сегодня с мы Олегом Чирухиным @olegchir - деврелом в Axiom JDK и топ-1 контрибьютором в блог Java на Хабре - поговорим о контейнеризации.

Привет, с вами команда разработки dBrain.cloud! Хотим поделиться историей миграции с Elasticsearch Beats Kibana (EBK) на Grafana Loki. Предпосылок перехода было немало: замена EBK лицензии Apache 2.0 на ограниченную SSPL 1.0, растущее потребление ресурсов, объемы требуемого места в хранилище и др. Сегодня покажем, как из грамотно подобранных и поселенных под одной крышей продуктов получилось собрать единый стек логирования и мониторинга.

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

Jenkins CI позволяет разработчикам автоматизировать создание, тестирование и развёртывание кода. Кроме того, он оттачивает возможности для обработки любой сборки или непрерывной интеграции. Jenkins Jobs фокусируется на непрерывном создании и тестировании кода, чтобы любые внесённые изменения легко интегрировались в сборку. В этой статье мы посмотрим на Jenkins в действии — разберём, как создавать и настраивать Jenkins Jobs. 

Это история о том как небольшая группа IT-шников хотела автоматизировать свою работу, а в результате решила переизобрести DevOps-заново, и (с точки зрения этой группы) добилась прогресса.

От предыдущего этапа нашей деятельности у нас осталось множество IT-разработок. Какие-то остались недоделанными, какие-то были выпущены в продакшен, какие-то были опубликованы как open source, какие-то остались закрытыми, какие-то нужно было архивировать, а какие-то опубликовать как демо-версии. Всё было свалено в кучу на нескольких VPS-ках. И чтобы продолжать деятельность, стало важно привести все это во вменяемый вид...