IT Lead
Deployment и DeploymentConfig — это, казалось бы, похожие объекты API для OpenShift Container Platform. Но на самом деле они предлагают разные гибкие методы управления интерфейсом пользователей. Расскажем о различиях и приведём примеры, когда какие объекты лучше использовать.
Логирование — это один из трех столпов мониторинга в распределенных системах. Мы можем видеть бурное развитие популярных продуктов с открытым исходным кодом типа ELK stack, и полноценных коммерческих продуктов, которые помогают с проблемами протоколирования в больших масштабах — Splunk, к примеру. Однако в таких сложных системах как Kubernetes протоколирование остается сложной проблемой. Она усугубляется постоянным ростом объема данных из–за всё большего внедрения контейнеризации.
В этой статье мы рассмотрим различные виды логов Kubernetes, необходимых для улучшения системы мониторинга, уделим внимание подходам к сбору, агрегации и анализу логов. Также мы приведем решение с использованием open source-сервисов Fluentd и Fluent Bit — оно упростит сбор данных.
Event storming — метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему. Он нередко используется в контексте моделирования микросервисов. Но как применить его на практике?
При создании системы на микросервисах можно легко получить распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск этого события. О том, как именно этого добиться, рассказал в своем докладе на конференции TechLead Conf 2020 практикующий консультант по архитектуре, процессам разработки и продуктовым практикам Сергей Баранов.
Хабр, привет!
Нас зовут Дмитрий Фролов и Владимир Мясников.Мы стандартизировали подход по документированию внутренних систем в команде интеграционного тестирования Мир Plat.Form с помощью «Модели С4».
Платежная платформа «Мир» представляет из себя десятки систем и сотни интеграций, за работоспособность которых отвечает наша команда. Разобраться новичку, и даже опытному сотруднику, в происходящем бывает непросто, и сегодня мы расскажем, как помогаем коллегам быстро и удобно получать информацию о наших системах.
Давайте разберемся, что такое «Модель С4» и какие задачи она помогает решать. С чего начать, если вам поступила задача задокументировать «большую» систему – читайте под катом.
Мониторинг очень важен для современных приложений, современные приложения по своей природе сильно распределены и имеют разные зависимости, такие как база данных, службы, кеширование и многое другое. Поэтому все более важны отслеживание и мониторинг этих служб, чтобы приложение придерживалось условий SLA ( Service Level Agreement). SLA — это соглашение между клиентом и поставщиком услуг, в нем учитываются надежность, скорость отклика и другие показатели уровня обслуживания.
Мы всегда стараемся не нарушать никаких SLA, нарушение любой части SLA может иметь множество последствий. Если услуга не соответствует условиям, определенным в SLA, она можкт нанести ущерб репутации бренда и привести к потери дохода. Хуже всего то, что компания может потерять клиента в пользу конкурента из-за своей неспособности удовлетворить требования клиента к уровню обслуживания.
Продолжаем беседовать с разработчиками экосистемы сервисов Serverless. В прошлый раз Глеб Борисов рассказал о возможностях и перспективах функций в Yandex.Cloud, сегодня Данил Ошеров погрузит нас в мир бессерверных систем и сервис Object Storage.
У меня был опыт разработки систем, обеспечивающих доступность файлов в разных дата-центрах. Мне надо было синхронизировать файлики, для чего пришлось разрабатывать целую систему, и я был не одинок в такой работе, это делали практически все разработчики корпоративного ПО.
Со временем такие системы перестали быть актуальными, они ушли на второй план, а на смену пришли новые, построенные по протоколу S3. Почему так случилось? Почему S3 стал «главным» протоколом для синхронизации данных?
Это вторая статья из цикла. В первой, вводной, я рассказывал, как устроены метрики для сервисов, чем отличаются от логов, и какую задачу вообще решают. Теперь подробнее про то, как их готовить.
Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.
Мониторинг сегодня – фактически обязательная «часть программы» для компаний любых размеров. В данной статье мы попробуем разобраться в многообразии программного обеспечения для мониторинга и рассмотрим подробнее одно из популярных решений – систему на основе Prometheus и Grafana
В любой сети, где есть больше, чем один сервер, очень полезно бывает иметь перед глазами полную картину происходящего. В крупных сетях, где количество хостов переваливает за несколько десятков, следить за каждым в отдельности — непосильная задача для администраторов. Для облегчения задачи наблюдения применяются системы мониторинга, и я расскажу об одной из них, которой на Хабре не посвящено ни одной полноценной статьи.
Обратите внимание, что данная статья подходит только для версии Directum RX ниже 4.1. Не используйте эту статью для более новых версий Directum RX. Информация и рекомендации, приведенные в этой статье, предоставлена только для ознакомительных целей и не может служить заменой профессиональных консультации Службы поддержки DIRECTUM.
Недавно я осознал нехватку вводных обучающих материалов о современной сетевой балансировке и проксировании. Я подумал: «Почему так? Балансировка нагрузки — одна из ключевых концепций для построения надёжных распределённых систем. Ведь должна быть доступна качественная информация об этом?» Я поискал и обнаружил, что информации мало. Статьи в Википедии о балансировке и прокси-серверах содержат обзоры некоторых концепций, но не могут похвастаться последовательным описанием предмета, особенно в том, что касается современных микросервисных архитектур. Поиск в Google информации о балансировке в основном возвращает сайты вендоров, заполненные модными терминами и скупые на подробности.
В этой статье я постараюсь восполнить нехватку постепенного введения в современную сетевую балансировку и проксирование. По правде сказать, это объёмная тема, достойная целой книги. И чтобы статья не получилась безразмерной, я постарался ряд сложных задач подать в виде простого обзора.
Базы данных (БД) существуют с первых дней программирования, а появились они ещё раньше. Это — неотъемлемые части любых приложений. Хорошо спроектированная БД — это один из важнейших компонентов, влияющих на производительность программных проектов. Из-за этого множество архитекторов программных решений исследовали массу подходов к управлению данными, пытаясь выяснить то, какие из этих подходов работоспособны в определённых сценариях, а какие — нет. Выбор подходящей архитектуры БД обычно сводится к выбору между SQL и NoSQL, между реляционными и нереляционными базами данных. А иногда в одном проекте используют и то, и другое.
В этой статье мы сделаем краткий обзор баз данных, поговорим об их истории, постараемся разобраться с тем, что собой представляют базы данных SQL и NoSQL, выясним ключевые различия между ними.
Apache Cassandra - это распределенная NoSQL база данных. В этой статье будут описаны основные механизмы передачи, репликации и поддержания согласованности данных внутри сети.
Я не очень понимаю, почему об этом мало кто рассказывает.
Есть две на редкость противоположные сущности: банковские требования к производству кода и желание как-то гибко разрабатывать. В итоге получилось два страшных типа команд: те, кто работал по плану и стабильно делал релиз раз в полгода, и те, кто работал по аджайлу и не делал релиз раз в неделю.
Почему модные и молодёжные аджайл-команды релиз не делали? Потому что у них было готово всё кроме одной мелочи — например, разработанных и согласованных архитектурных документов на решение с инетрпрайз архитектором и безопасником. То есть процесс, который можно условно назвать «ГОСТ», приходил к ним в лице суровых грустных мужиков. И заставлял их проходить все этапы согласований, начиная с оценки возможного риска и заканчивая какими-то «совершенно ненужными» тестами, согласованиями требований с юристами и прочей хтонью, которая нормальному человеку покажется адом. Но именно по этому аду нужно было пройти, сделать с десятка два документов, согласовать каждый и только после этого выходить в продакшен. Где-то месяца через два.
Думаю, вы и сами представляете, как оно происходит в банках. Именно поэтому многие разработчики <sarcasm>так стремятся</sarcasm> в них работать.
Когда я прикоснулся в Газпромбанке к организации производства, то как раз застал несколько «ГОСТ-команд» с совершенно безнадёжным TTM и много аджайл-команд, бьющихся в истерике от требований.
В IT-компаниях сотрудникам часто приходится выступать перед коллегами: презентовать свое решение, отчитываться на регулярном митинге или просто делиться своим опытом. Но навык таких выступлений, пусть и перед небольшим количеством людей, есть не у всех.
Мы попросили поделиться своим опытом Романа Неволина, который регулярно участвует в IT-конференциях и выступает с докладами публично. Он расскажет, зачем вообще выступать перед коллегами и как правильно построить выступление, чтобы тебя слушали, слышали и понимали.
Angular — это достаточно большой фреймворк. Задокументировать и написать примеры использования для каждого кейса просто невозможно. И механизм внедрения зависимостей не исключение. В этой статье я расскажу о возможностях Angular DI, о которых вы почти ничего не найдете в официальной документации.