Рубрика «devops» - 22

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

Можно спросить, а причем здесь техдолг, если конференция DevOps? Холиварить об этом можно, например, в рамках DevOps-фуршета, но настолько ли это широкое понятие? Мы узнали, что Артем относит к техдолгу все изменения и доработки, инфраструктурные модификации и изменения процессов, изменения структур команд, направленные на устранение гэпов — которые были допущены (осознанно или нет) в рамках запуска продуктов и фич, и которые со временем сильно мешать жить.

А так как такие вещи невозможно исправить без твердой и уверенной спайки производственного и операционного цехов, то и получается, что эта история напрямую — про DevOps.

Техдолг. Все говорят: «невозможно», а я говорю, что буду - 1
Читать полностью »

Изучаем ELK. Часть I — Установка Elasticsearch - 1

Вступительное слово

Эта статья является первой в серии статей по стеку Elasticsearch, Logstash, Kibana (ELK). Цикл статей ориентирован на тех, кто только начинает знакомится со стеком ELK, и содержит минимально необходимый набор знаний, чтобы успешно запустить свой первый кластер ELK.

В рамках данного цикла будут рассмотрены такие темы, как:

Хранение данных в Docker - 1

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

В этой статье рассмотрим docker volumes, bind mount и tmpfs, дадим советы по их использованию, проведём небольшую практику.

Читать полностью »

IT-словарик для не-айтишников - 1

Приходилось ли вам объяснять IT-понятия людям из других сфер? Это хитрая задача: при объяснении одного IT-термина нельзя пользоваться другими, потому что они тоже будут непонятными. Представим, что ваш знакомый захотел «войти в айти», впервые открыл Хабр и офигел — как объяснить такому человеку хотя бы основные слова?

Читать полностью »

Однажды я вел вебинар про то, как принимать 10 000 ивентов в секунду. Показал вот такую картинку, зрители увидели сиреневый слой, и началось: «Ребят, а зачем нам все эти кафки и рэббиты, неужели без них не обойтись»? Мы и ответили: «Зачем-зачем, чтобы пройти собес!» 

Неужели нельзя обойтись без кафок и рэббитов, когда принимаешь 10 000 ивентов в секунду - 1

Очень смешно, но давайте я все-таки объясню.


Читать полностью »

Прогресс shell-operator и addon-operator: хуки как admission webhooks, Helm 3, OpenAPI, хуки на Go и многое другое - 1

Shell-operator и addon-operatorЧитать полностью »

Читать полностью »

Мотивом для написания данной статьи послужил тот факт, что на habr.com участилось появление материалов маркетингового характера про Apache Kafka. А также тот факт, что из статей складывается впечатление что пишут их немного далекие от реального использования люди — это конечно же только впечатление, но почему-то в большинстве своем статьи обязательно содержат сравнение Apache Kafka с RabbitMQ, причем не в пользу последнего. Что самое интересное — читая подобные статьи управленцы без технического бэкграунда начинают тратить деньги на внутренние исследования, чтобы ведущие разработчики и технические директора выбрали одно из решений. Так как я очень жадный/домовитый, а также так как я сторонник тезиса "В споре НЕ рождается истина" предлагаю вам ознакомится с другим подходом — почти без сравнения разных брокеров.

Читать полностью »

Вы думаете, что выбираете технологию потому, что она подходит требованиям? Вы можете ошибаться.

Давайте начнём с примера, который, возможно, вдохновлён реальной ситуацией. Команде необходимо подобрать брокера событий. Претендента два — Kafka и Pulsar.

Разработчик А имеет значительный опыт с Kafka в реальных ситуациях. Упоминают сложность при масштабировании Kafka и поручаются Pulsar. Разработчик B — сторонник Kafka, так как технология стала стандартом индустрии и имеет сильную поддержку в целом. Но у команды мало опыта работы с ней. Оба согласны в том, что в обозримом будущем изменений рабочей нагрузки нет и два этих решения соответствуют требованиям. Но остальные члены команды не так самоуверенны.

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

Но раскрыты ли истинные мотивы выбора?

Человеческое эго и стремления — движущие силы инженерных решений - 1


Читать полностью »

Аварии как опыт #1. Как сломать два кластера ClickHouse, не уточнив один нюанс - 1

Про некоторые свои failure stories мы уже писали и раньшеЧитать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js