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

Я интересуюсь сетями, и решил посмотреть, как в Go реализуется работа с протоколами ICMP и ICMPv6. Наиболее простая задача, связанная с ними, — реализация программы ping. Она отправляет указанному узлу сети запросы ICMP типа Echo-Request и ожидает ответы типа Echo-Reply.

На первый взгляд — простейшая задача, поэтому усложним ее: построим приложение, похожее на утилиту ping в UNIX-подобных системах. Под катом расскажу, как я решал задачу и с какими подводными камнями столкнулся.

Я сам родился и вырос в Казахстане, высшее получал уже в Томске, поэтому в Казахстане у меня друзья детства, да и сестра до сих пор живет в Караганде. Хотел купить машину, но в Томске не нашел, поэтому попросил друга детства поискать вариант в Казахстане. На днях он позвонил: немецкое авто за очень интересные деньги. Продавал его знакомый, машину мой друг знал с момента приобретения её в салоне. Вердикт - Надо брать!

Деньги человеку нужны были срочно, хотя бы 400 тысяч до вечера. Договорились по телефону: 400 тысяч аванс, а потом уже не торопясь приеду отдам остальную сумму, оформимся. Друг мой выступил гарантом.

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

Мы успешно обновили кластер PostgreSQL с версии 13 до 16, обеспечив минимальный простой и высокую производительность. Процесс включал в себя создание новой реплики через логическую репликацию, перенос роли мастера на обновлённую реплику и настройку потоковой репликации. Несмотря на некоторые сложности, такие как управление LSN и проблемы с подписками, нам удалось сохранить данные и обеспечить синхронизацию.

Подробности читайте в статье.

Как и многие, я храню свой код на GitHub. Пару лет назад я сделал простой пайплайн для сборки, анализа и тестирования моих веб‑приложений и сервисов. Он выполнял свою задачу, и так как это был мой первый опыт по настройке пайплайна CI/CD на GitHub, он сводился к одному шагу.

build (and deploy)

Со временем я стал замечать, что я стараюсь избегать вносить изменения в код. Будучи счастливым обладателем ADHD, я часто замечаю за собой сложность в решении задач с большим количеством препятствий и одним из них стало то, что выполнение пайплайна занимало больше 5 минут. Я коммитил изменения и шел делать кофе, пока пайплайн тестировал и деплоил код. И не всегда возвращался, отвлекаясь на другие вещи.

Я решил для себя, что максимальное количество времени, которое я готов ждать - 1 минута.

Привет, Хабр! Сегодня рассмотрим изоляции процессов и управления ресурсами в Linux, изучив возможности cgroups и namespaces. Разберёмся, как работают контейнеры изнутри и научимся создавать собственное изолированное окружение без Docker.

Для работы с проектами существует куча редакторов кода и IDE (VSCode, NeoVim, SublimeText, WebStorm и т.д.). В данный момент наиболее популярны VSCode и Webstorm и у каждого есть свои плюсы и минусы. Webstorm является примером прекрасного IDE от компании JetBrains, где многие вспомогательные модули идут “из коробки”. К сожалению, сейчас нет возможности легально получить доступ к этому продукту гражданам России, поэтому многим приходится искать альтернативу. Такой альтернативой вполне может стать Visual Studio Code от компании Microsoft, который имеет открытую кодовую базу, полностью бесплатный и гибко настраиваемый под ваши нужды. В данной статье мы рассмотрим пример настройки рабочего пространства VSCode для комфортной работы с нашими проектами. Я покажу вам, какими расширениями я пользуюсь для лучшего удобства и продуктивности. Эти расширения я использую давно и они хорошо зарекомендовали себя, но возможно некоторые из них могут не подойти под ваш стиль работы и написания кода. Итак, начнем!

Сейчас OpenTelemetry — это самый быстрорастущий проект CNCF. Опытом внедрения этого набора инструментов для отладки и анализа производительности распределённых систем поделился тимлид платформенной команды Норвежского управления труда и социального обеспечения. В переводе под катом вас ждёт тернистый путь от первых коммитов до реального применения OpenTelemetry в production, а также планы команды на будущее.

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

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

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

Я Сергей Задорожный, руководитель отдела платформенных решений банка «Центр-инвест» и один из авторов курса «DevOps для эксплуатации и разработки» от Яндекс Практикума. Раньше занимался написанием бэкендов на Java и Kotlin, потом занялся архитектурой, выстраиванием процессов, а сейчас заношу DevOps-практики в финтех-энтерпрайз.

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

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

Фармацевтическая компания Fox-Meyer Drugs, стоившая порядка 40 миллиардов долларов, из-за неверного внедрения ERP системы обанкротилась и была продана конкурентам за 80 миллионов долларов. Банкротство произошло потому, что складская логистика компании не измерялась, не мониторилась, не была охвачена ни метриками, ни показателями, ни KPI. При внедрении ERP не заметили разрушение ключевых бизнес-процессов: склады оказались переполнены, клиенты не получали продукцию. В компании отслеживалась прибыль, но не были формализованы логистические бизнес-процессы, которые разрушились за несколько дней. Отсутствие управления—неприятный нюанс, присутствующий на всех предприятиях. Это нужно принять, как данность, вопрос критичности, в том, какие зоны предприятия неуправляемы.

Всем привет! Меня зовут Николай Первухин, я Senior Java Developer в Райффайзенбанке. В последнее время я активно занимаюсь BPM-системами Camunda и Zeebe (основа Camunda-cloud). Если вы, как и я, с ходу не можете ответить на вопрос, кто быстрее — Camunda или Zeebe, насколько, и в каких случаях они могут тормозить, то добро пожаловать под кат.

1 Терминология

В «Надежность в процессах. Часть 1» [OpRes24-1] были определены (упрощены): надежность, процесс и надежность в процессах. Надежность – это способность безотказно работать (работать без отказов). Надежность процесса – это как способность безотказно работать («главное процесс»), так и выдавать требуемый результат («главное результат»). Количественно – это вероятность безотказной работы (вероятность застать процесс работоспособным) и вероятность требуемого результата на выходе процесса.

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

Это относится как ИТ-системе (кластер серверов) и не ИТ-системе (сейф), так и к системе процессов (операций) и составных частей процесса, включая его ресурсы.

Если в классической теории надёжности (Надёжность в технике [27.002]) обычно рассматриваются внутренние воздействующие деструктивные факторы на техническую систему типа отказ \ сбой оборудования \ ПО, то «Надежность в процессах и операциях» (операционная надёжность) рассматривает также непреднамеренные ошибки персонала (операционные риски) и внутреннее мошенничество, внешние атаки на процессы компании, клиентов компании (социальная инженерия), стихийные бедствия (техногенные катастрофы). В конечном счете неважно: «система процессов» отказала (не выполнила задачу) из-за какой-либо поломки или из-за ее перегрузки (от нежданного «наплыва клиентов» до DDoS-атаки), поэтому в состав показателей Надежность в процессах добавляем «доступность»:

Представляю вашему вниманию третью (заключительную) часть перевода статьи A guide to inter-process communication in Linux.

Первая часть перевода была посвящена общему введению в курс дела и механизму разделяемого хранилища (shared storage). Во второй части были рассмотрены механизмы каналов (именованных и неименованных) и очереди сообщений. В третьей части автор статьи ставит перед собой цель рассказать вам о сокетах и сигналах; подводит общие итоги по межпроцессному взаимодействию в Linux.

Приятного чтения!

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

Согласитесь, было бы здорово узнавать о проблемах раньше, чем пользователи начнут жаловаться в поддержку. Сегодня я расскажу, как мы в Циан создавали Техническую Мобильную Аналитику (ТьМА) и получили возможность в любой момент времени ответить на вопрос: «Всё ли в порядке с приложением?»

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