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

Этой осенью Яндекс.Маркету исполняется 18 лет. Все это время развивается партнерский интерфейс Маркета. Если кратко, то это админка, с помощью которой магазины могут загружать каталоги, работать с ассортиментом, следить за статистикой, отвечать на отзывы и т.д. Специфика проекта такова, что приходится очень много взаимодействовать с различными бэкендами. При этом данные не всегда можно получить в одном месте, из одного конкретного бэкенда.

Введение

Сегодня мы хотим обсудить практическую сторону внедрения концепций Service Level Objectives и Service Level Indicators. Рассмотреть, что входит в понятия SLI, SLO и Error budget, как рассчитывать эти показатели, как за 7 шагов внедрить их отслеживание и как в последствии контролировать эти показатели на примере инструмента Instana.

Определимся с терминологией

Service Level Indicator (SLI) – это количественная оценка работы сервиса, как правило, связанная с удовлетворенностью пользователей производительностью приложения или сервиса за заданный период времени (месяц, квартал, год). А если говорить конкретнее – это индикатор пользовательского опыта, который отслеживает одну из многочисленных возможных метрик (рассмотрим их ниже) и, чаще всего, представляется в процентном эквиваленте, где 100 % - означает отличный пользовательский опыт, а 0% - ужасный.

Service Level Objectives (SLO) – это желаемое, целевое значение нашего SLI или группы SLI. При установке SLO необходимо указывать реально достижимое значение для каждого конкретного SLI. Ниже мы рассмотрим логику установки SLO на примере конкретных SLI.

Также важно понимать, что SLO – это наш внутренний показатель качества работы сервиса и/или приложения, в отличие от Service Level Agreement (SLA), который обычно устанавливается бизнесом как внешнее обязательство по доступности сервиса перед клиентами компании.

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

Но вот только понять я одного не могу. Порой приходишь в бар, просишь пива. И тебе вроде бы даже приносят в красивой кружке, и вроде бы вкусно, но за что 500 рублей за 0.5 литра? Если я в магазине баночку за 80 рублей куплю, будет заметно хуже?

Что же, подумала я, не зря же училась? Расчехляем бумажку с ручкой, будем выяснять, оправдана ли для меня лично переплата. А заодно ознакомимся с азами математической статистики — пожалуй, одной из важнейших дисциплин в науке в целом.

❓Как проектировать системы, которые будут толерантными для различного вида отказов и ошибок?

Что такое отказоустойчивость и стабильность?

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

1. Деградация работоспособности системы должна быть прямо пропорциональна "величине" отказа. То есть, если упал сервис, отвечающий за некую некритичную функциональность — вся система не должна при этом падать. Да, небольшой кусочек не работает, но это не влияет на стабильность остальной части функционала.

2. Стабильность системы предполагает самостоятельного восстановления работоспособности после сбоя как компонентов системы, так и всей системы в целом. К примеру, если пропадала сеть на некоторое время — то у стабильных систем после восстановления подключения все компоненты продолжат работать и данные вернутся в консистентное состояние без ручного вмешательства со стороны команды эксплуатации.

Мы в Авито разработали свою внутреннюю платформу для разработчиков. Несмотря на то, что создание платформенного продукта — довольно затратная история, в итоге мы видим сплошные плюсы. Она растит скорость и качество разработки, делает системы стабильнее, помогает инженерам сосредоточиться на бизнес-задачах, а не на рутине. 

Наш опыт построения платформы мы постарались заложить во внешнее решение Plato, которое опирается на проверенные open-source решения.

О преимуществах платформы, процессах её разработки и сложностях в реализации — в этой статье.

Как подготовиться к собеседованию

Общие сведения о TLS

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

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

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

Администратор любой IT системы должен знать о всех возможных проблемах, которые могут возникнуть на вверенном ему оборудовании: аппаратные сбои системы хранения, сбои файловой системы, повреждения страниц в оперативной памяти, сбои в кэше хранилищ и так далее. Для серверов баз данных выявление и исправление таких ошибок особенно важно, так как информация в БД должна быть в согласованном состоянии и некорректность только части данных портит БД целиком. В этой статье мы расскажем с помощью каких инструментов можно защитить ваши данные в СУБД Postgres и обнаруживать ошибки до того, как они становятся реальными проблемами.

Эта статья является переводом материала «Cohesion and Coupling: the difference». 

Возможно, вы слышали рекомендацию, в которой говорится, что мы должны стремиться к достижению low coupling (низкой связанности) и high cohesion (высокого сцепления) при работе над кодовой базой. В этой статье хотелось бы обсудить, что на самом деле означает эта рекомендация, и взглянуть на некоторые примеры кода, иллюстрирующие ее. И также хочется провести границу между этими двумя идеями и показать различия в них.

Выбирая замену, используемой у нас системы обмена сообщениями, наткнулся на описание Mattermost, и решил попробовать. Одним из плюсов, описываемой системы, является простая интеграция со сторонними сервисами, так называемые "хуки" (outgoing и incoming hooks). Вот про настройку взаимодействия через хуки с внешними системами и будет данная статья (в нашем конкретном случае это zabbix и glpi).

Когда я только знакомился с принципами SOLID, я искал понятные статьи на Хабр. При этом пришлось прочитать не одну статью, и полное понимание пришло сильно позже. Хотелось бы, чтобы новички на более простых примерах смогли почувствовать, о чем эти принципы.

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

Изнуряющие тренировки отнимают много времени и сил. Зато потом, когда понадобится применить своё искусство,  тело сделает всё само — «на автомате». А ценные ресурсы мозга будут освобождены для решения более важных задач — стратегического планирования, принятия ключевых решений, поиска новых возможностей. И, конечно, для творчества.

А что же программисты?...

Введение

• Information Expert
• Creator
• Controller
• Low Coupling
• High Cohesion
• Polymorphism
• Pure Fabrication
• Indirection
• Protected Variations

Если возникает вопрос об описании архитектуры системы, то есть несколько основных решений где и как это сделать. Среди популярных нотаций для визуализации схемы архитектуры можно выбрать C4, разработанную Саймоном Брауном.

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

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

Эта статья является конспектом материала Effective Aggregate Design Part II: Making Aggregates Work Together.

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

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