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

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

Зачем вообще нужны микросервисы

Архитектура микросервисов — это не универсальное решение, а альтернативный подход к построению систем.

Микросервисы подходят не для всех проектов. Они оправданы, когда:

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

Монолит часто лучше для:

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

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

Микросервисы работают иначе. Это сеть специализированных магазинов, расположенных в одном торговом центре. Хлебный магазин, мясная лавка, овощной павильон. Каждый работает независимо. Если в хлебном магазине ремонт, мясная лавка продолжает работать.

Конкретные преимущества микросервисов:

• Независимое развертывание. Можно обновлять один сервис без остановки всей системы.
• Масштабируемость. Сервисы с высокой нагрузкой масштабируются отдельно от остальных.
• Технологическая гибкость. Разные сервисы можно писать на разных языках и технологиях.
• Устойчивость к ошибкам. Если один сервис упадёт, это не приведёт к коллапсу всей системы.

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

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

Ошибка 1: Распределенный монолит

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

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

Реальный кейс: Консультант IBM Холли Каммингс описывает проект, где команда жаловалась: «каждый раз, когда мы меняем один микросервис, ломается другой». Сервисы были распределены по разным репозиториям, но использовали идентичные копии сложной объектной модели. Изменение одного поля требовало синхронного обновления всех сервисов. Команда потеряла преимущества монолита — компилятор больше не проверял типы, — но не получила преимуществ микросервисов — независимости развёртывания.

Как избежать:

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

Распределённый монолит — это худший из возможных сценариев. Вы получаете сложность распределённых систем без преимуществ модульности.

Ошибка 2: Чрезмерное дробление сервисов (декомпозиция)

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

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

Реальный кейс: Компания Gilt перешла на микросервисы в 2015 году и столкнулась с проблемой излишнего дробления. Изначально они создали более 450 микросервисов для платформы электронной коммерции. Многие сервисы были настолько малы, что выполняли лишь одну простую функцию. Это привело к экспоненциальному росту операционных расходов. Команда тратила больше времени на координацию взаимодействия между сервисами и устранение сетевых сбоев, чем на разработку новой функциональности. В итоге они провели рефакторинг, объединив сервисы с высокой связностью, что значительно упростило систему и ускорило разработку .

Как найти баланс:

• Объединяйте функциональности с высокой связностью. Если два компонента постоянно общаются, возможно, они должны быть одним сервисом.
• Ориентируйтесь на функциональную связность. Сервис должен иметь чёткую зону ответственности в бизнес-логике.
• Оценивайте операционные расходы, прежде чем создавать новый сервис. Спросите себя: готовы ли мы поддерживать ещё одну базу данных, ещё один конвейер развёртывания?

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

Ошибка 3: «Болтливые» микросервисы

Микросервисы много общаются друг с другом. Мелкозернистые API вынуждают делать десятки вызовов для одной операции. Это создаёт каскады зависимостей, где сбой одного сервиса вызывает цепную реакцию.

В чем проблема: При такой структуре возникает следующий сценарий провала:

• Частые взаимодействия — сервисы обмениваются множеством мелких запросов, генерируя насыщенный сетевой трафик.
• Каскад вызовов — один пользовательский запрос запускает длинную цепочку обращений к разным сервисам.
• Мелкозернистые API — для выполнения одной бизнес-транзакции требуется множество вызовов.

Реальный кейс: Команда Amazon Prime Video столкнулась с проблемой производительности своей системы мониторинга видео. Изначально они построили архитектуру на основе микросервисов, где каждый этап обработки видео (метаданные, детекция дефектов, анализ качества) был отдельным сервисом.

Система состояла из множества «болтливых» сервисов, которые постоянно обменивались сообщениями через AWS Step Functions. Это привело к резкому росту затрат и проблемам с производительностью из-за постоянной сериализации/десериализации данных между сервисами. В итоге команда консолидировала несколько сервисов в единый монолит, что снизило затраты на 90% и улучшило производительность .

Решение:

• Используйте асинхронную коммуникацию через очереди событий.
• Проектируйте крупнозернистые API, которые охватывают полный бизнес-контекст за один вызов.
• Внедряйте архитектурные паттерны типа API Gateway для агрегации данных и Backend For Frontend для оптимизации под конкретные клиенты.

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

Ошибка 4: Игнорирование сквозной функциональности

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

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

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

Правильный подход:

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

Наблюдаемость как основа стабильности

Современные микросервисные системы требуют полноценной наблюдаемости (observability). Это не просто мониторинг, а понимание, что именно происходит внутри системы, без дополнительных вопросов к разработчикам.

Три столпа наблюдаемости:

1. Логи — записи о конкретных событиях с временными метками и контекстом.
2. Метрики — числовые показатели, отслеживаемые во времени (загрузка CPU, latency, error rate).
3. Трассировка — отслеживание пути запроса через распределённую систему.

Ошибка 5: Нечеткие границы сервисов

Сервисы без чётких границ начинают обрастать несвязанной функциональностью. Order Service вдруг получает отчётность, а Payment Service — нотификации. На выходе — монстр с размытой ответственностью.

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

Реальный кейс: Компания Kong (тогда еще Mashape) начала декомпозицию монолита в 2013 году. Монолитное приложение, написанное на Java, объединяло функциональность маркетплейса API, включая биллинг, аналитику и управление каталогом. В процессе декомпозиции команда столкнулась с трудностями, которые позже были признаны классическими ошибками.

Первоначально четкие границы между компонентами со временем размылись, что привело к серьезным проблемам:

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

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

Как избежать:

• Используйте Domain-Driven Design (DDD). Определяйте Bounded Context — чёткие границы бизнес-доменов.
• Перед созданием сервиса документально зафиксируйте его зону ответственности. Что он делает? Какими данными владеет?
• Сопротивляйтесь искушению добавить «ещё одну маленькую функцию» в существующий сервис. Часто лучше создать новый, но для начала нужно разобраться с конкретной задачей продукта.

Антипаттерн Entity Service

Частный случай размытых границ — создание сервисов по принципу «одна сущность — один сервис». Это кажется логичным: сервис пользователей, сервис заказов, сервис товаров. Но на практике такой подход создаёт ещё больше проблем. Entity Service (сервис одной сущности) часто превращается в обычный CRUD-интерфейс к базе данных. Вся бизнес-логика перемещается в вызывающие сервисы, которые вынуждены делать десятки вызовов для выполнения одной операции.

Альтернатива: Создавайте сервисы вокруг бизнес-операций, а не данных. Вместо общего «сервиса пользователей», который отвечает за всё подряд, выделите отдельные сервисы с конкретными зонами ответственности:

• сервис регистрации — создает новые учетные записи;
• сервис аутентификации — проверяет логины и пароли;
• сервис управления профилем — обновляет личные данные.

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

Ошибка 6: Смешивание баз данных

Общая база данных для нескольких микросервисов — это красный флаг. Сервисы теряют независимость. Изменение схемы данных одним сервисом ломает остальные.

В чем проблема: Единая база данных создает скрытую связность между сервисами. Невозможно выбрать оптимальную СУБД для конкретного сервиса — все используют одно решение. Затрудняется горизонтальное масштабирование.

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

Это создает тесную связность на уровне разработки и времени выполнения:

• Зависимость разработки. Разработчик, вносящий изменения в OrderService, должен согласовывать изменение схемы таблиц с командой, отвечающей за CustomerService, что значительно замедляет работу.
• Блокировки времени выполнения: Длительная транзакция в CustomerService, которая удерживает блокировку на таблице ORDERS, может полностью заблокировать работу OrderService.

Такой подход лишает микросервисы их ключевых преимуществ — независимости развертывания и масштабирования.

Правила работы с данными:

• У каждого сервиса должна быть собственная база данных. Сервис владеет своими данными — другие сервисы получают доступ только через его API.
• Используйте шаблон Saga для управления распределёнными транзакциями вместо двухфазного коммита.
• Реализуйте CQRS (Command Query Responsibility Segregation) для отделения операций записи от операций чтения, когда это необходимо.

Общая база данных создаёт жесткую зависимость между сервисами. Изменение схемы данных в одном месте может сломать функциональность в другом. Команды теряют возможность независимо развивать свои сервисы — любая правка требует согласования со всеми участниками.

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

Ошибка 7: Неготовность организации

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

Реальный кейс: в одной из компаний команда разрабатывала микросервис, но была вынуждена тесно интегрировать его с унаследованным монолитом. Они зависели от его цикла выпуска, что свело на нет все преимущества независимой разработки. Проект в итоге закрыли.

Какие организационные изменения помогут:

• Перейдите к командам по сервисам — небольшим автономным группам, которые полностью владеют своими сервисами (You Build It, You Run It).
• Внедрите культуру DevOps — автоматизацию сборки, тестирования и развёртывания для каждого сервиса.
• Наладьте независимые циклы выпуска. Возможность развёртывать сервисы без координации с другими командами — ключевое преимущество микросервисов.

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

Что меняется:

• Ответственность. Разработчики отвечают не только за написание кода, но и за работоспособность сервиса в продакшн.
• Коммуникация. Команды должны чётко определять контракты между сервисами и соблюдать их.
• Экспертиза. Появляется потребность в специалистах по DevOps, наблюдаемости, распределенным системам.

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

Чек-лист для вашего перехода

Прежде чем переходить на микросервисы, проверьте себя по этому списку:

• вы определили бизнес-проблему, которую будете решать микросервисами (а не просто хотим «быть как Netflix»);
• спроектировали границы сервисов на основе бизнес-доменов — DDD, Bounded Context;
• у каждого сервиса будет собственное хранилище данных;
• предусмотрели кросс-каттинговые сервисы — логирование, аутентификацию, мониторинг;
• готовы к организационным изменениям — автономные команды, DevOps;
• выбрали правильный уровень детализации сервисов (не слишком мелкий);
• продумали межсервисную коммуникацию — асинхронную, через события.

Netflix, Amazon и Uber прошли этот путь. Они не избежали ошибок, но выстроили процессы для развития сложных систем. Микросервисы — это эволюция архитектуры и команды. Начинайте с малого, не бойтесь менять решения. Главный критерий успеха — скорость доставки ценности пользователям без поломок продакшена. Если этот показатель растет — вы на правильном пути.

Одним из таких инструментов является статический анализатор кода. О статическом анализе и его пользе для встраиваемых систем и пойдёт речь в этой статье.

Статический анализ кода

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

Статический анализатор кода — это ПО, которое проводит анализ программы без её реального выполнения. Инструменты статического анализа проводят более глубокую проверку исходного кода, чем это делает компилятор, который обычно находит только синтаксические ошибки. Их принцип работы заключается в следующем:

• на вход принимают исходный код проекта (желательно компилируемый);
• преобразуют исходный код в специальную модель для дальнейшего анализа (AST, семантическая информация и так далее);
• ищут дефектные места, применяя к модели набор диагностических правил, в основе которых лежат различные методологии;
• сохраняют все полученные предупреждения в удобный для вас формат;
• остаётся только изучить отчёт и исправить все дефектные места;
• PROFIT!

Статические анализаторы применяются для широкого спектра задач. Можно выделить наиболее распространённые:

Поиск ошибок в программном коде (наиболее распространённое применение). В этом плане статический анализ здорово дополняет процесс обзора кода, позволяя найти и исправить ряд проблем до того, как засядете на долгое время с коллегой.

Улучшение качества кода в широком смысле этого слова. К качеству можно отнести читаемость, поддерживаемость, сложность кода, уровень связанности и другие аспекты, которые прямо или косвенно могут влиять на количество ошибок. Тем самым, статические анализаторы могут помогать следовать стандартам кодирования (как принятым внутри компании, так и общепринятым).

Анализ кода как часть механизма Quality Gates в CI/CD. Анализаторы могут не только сообщать о наличии возможных ошибок в коде, но и служить защитным механизмом, предотвращающим доставку кода, если уровень его качества не соответствует заданным требованиям. Такую роль могут выполнять анализаторы кода, расширяющие поведение компилятора и блокирующие сборку, если были обнаружены ошибки или несоответствия кода принятым стандартам;

Сбор метрик проекта, сбор статистики, построение графиков и диаграмм, отражающих общее «состояние здоровья» проекта.

Польза внедрения

Польза от внедрения статического анализатора в разработку встроенного ПО несомненна. Давайте рассмотрим самые очевидные положительные стороны использования статического анализа.

Использование статического анализа позволит уменьшить вероятность дорогой, а то и вовсе невозможной «перепрошивки» уже выпущенных устройств

Ошибки в ПО встраиваемых систем крайне неприятны. Неприятность в том, что ошибки невозможно или почти невозможно исправить, если началось серийное производство. Если уже выпущены сотни тысяч стиральных машин и они разъехались по магазинам, то что делать при обнаружении неадекватной работы машины в определённом режиме? В общем-то вопрос риторический и реальных вариантов два:

1. Смириться и получать негативные отзывы клиентов на различных сайтах, портя свою репутацию. Можно, конечно, выпустить и разослать к инструкции приложение «не делайте вот так», но это тоже слабый вариант;
2. Отозвать серию и заняться обновлением прошивок. Дорогое развлечение.

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

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

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

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

Статические анализаторы кода значительно удешевляют процесс тестирования и отладки программ

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

Наверняка у каждого разработчика была неудачная попытка «прошить» устройство, в результате чего, например, оно некорректно держало заданное напряжение или вовсе перегорало. Что произошло и где искать проблему? Ведь причиной этому может быть не только программная ошибка, но и ошибка в самом «железе» или в некачественном изготовлении макета. В результате процесс поиска ошибки может сильно затянуться. Самый обидный сценарий:

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

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

А предыстория этой ошибки такая. За основу были взяты наработки от предыдущего проекта, и код во многом написан методом Copy-Paste. По невнимательности разработчик в одном месте забыл заменить 4 на 3. Как итог, неопределённое поведение при обращении к индексу за пределами массива. Коварность такого кода в том, что при отладке программа может работать корректно, а в реальных условиях при многократном запуске у клиента может происходить сбой. Великолепно, если такую ошибку найдёт статический анализатор.

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

Использование статического анализа позволит подстраховать разработчика с недостаточной экспертизой

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

Статические анализаторы имеют базу знаний о различных паттернах, которые в определённых условиях приводят к ошибке. Поэтому они могут указать программисту на ошибку, о существовании которой он сам вряд ли бы догадался. Примером может служить использование 32-битного типа time_t, который может привести к неправильной работе устройства после 2038 года.

Другим примером может служить неопределённое поведение программы, которое возникает из-за неправильного использования операторов сдвига <</>>. Эти операторы очень широко используются в коде микроконтроллеров. К сожалению, программисты часто используют эти операторы крайне неаккуратно, делая программы ненадёжными и зависимыми от версии и настроек компилятора. При этом программа может работать, но вовсе не потому, что написана правильно, а потому, что везёт.

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

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

Для встраиваемых систем популярными языками программирования считаются C и С++. Именно для них были разработаны такие стандарты, как MISRA C, MISRA C++ и AUTOSAR C++. Каждый стандарт имеет немалое количество правил и рекомендаций (MISRA C: 143, MISRA C++: 228, AUTOSAR C++: более 350), придерживаться которых при кодировании просто невозможно без статических анализаторов кода.

Правила представляют собой паттерны кодирования, которые необходимо избегать, тем самым уменьшая вероятность допустить ошибку. Сейчас все крупные игроки статического анализа (Coverity, Klockwork, PVS-Studio и так далее) стремятся к тому, чтобы максимально покрыть эти стандарты в своих инструментах.

Стандарты кодирования

История MISRA началась достаточно давно. В начале 90-x правительственная программа Великобритании под показательным названием «Safe IT» выделяла финансирование для различных проектов, так или иначе связанных с безопасностью электронных систем. Сам проект MISRA (Motor Industry Software Reliability Association) был основан ради создания руководства по разработке ПО для микроконтроллеров в наземных транспортных средствах – в машинах, в общем.

MISRA (как организация) – это содружество заинтересованных сторон из различных авто- и авиастроительных индустрий:

• Bentley Motor Cars;
• Ford Motor Company;
• Jaguar Land Rover;
• Delphi Diesel Systems;
• HORIBA MIRA;
• Protean Electric;
• Visteon Engineering Services;
• The University of Leeds;
• Ricardo UK;
• ZF TRW.

Весьма сильные игроки рынка. Неудивительно, что их первый связанный с языком стандарт — MISRA C — стал общепринятым среди разработчиков критически важных встраиваемых систем. Чуть позже появился и MISRA C++. Постепенно версии стандартов обновлялись и дорабатывались, чтобы охватывать новые возможности языков. На данный момент актуальными версиями являются MISRA C: 2012 и MISRA C++: 2008.

Отличительные черты MISRA: невероятное внимание к деталям и крайняя дотошность. Авторы не просто собрали в одном месте все пришедшие в голову «дыры» C и C++ (как, например, авторы CERT) — они тщательно проработали международные стандарты этих языков и выписали все возможные способы ошибиться. А потом взяли и сверху дописали правила и рекомендации про читаемость кода. Ведь в простом и легко читаемом коде тяжелее допустить ошибку и легче её обнаружить при Code-Review.

Зачастую у людей, которые впервые сталкиваются с MISRA, складывается мнение, что философия стандарта заключается в «запретить вон то и запретить вот это». На самом деле, это так, но лишь отчасти.

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

В MISRA C правила делятся на три основных категории: Mandatory, Required и Advisory. Mandatory — это правила, которые нельзя нарушать ни под каким предлогом. Например, в этот раздел входит правило «не используйте значение неинициализированной переменной». Required-правила менее строги: они допускают возможность отклонения, но только если эти отклонения тщательно документируются и письменно обосновываются. Остальные правила входят в категорию Advisory — это правила, которым следовать необязательно.

В MISRA C++ немного по-другому: там отсутствует категория Mandatory, и большинство прави принадлежит к категории Required. Поэтому, по сути, вы имеете право нарушить любое правило — только не забывайте документировать отклонения. Также там есть категория Document — это обязательные к выполнению правила (отклонения не допускаются), которые связаны с общими практиками вроде «Каждое использование ассемблера должно быть задокументировано» или «Подключаемая библиотека должна соответствовать MISRA C++».

Помимо описания проблематики, в стандарте содержится большое количество советов о том, что нужно знать перед началом работы: как наладить процесс разработки по MISRA; об использовании статических анализаторов для проверки кода на соответствие; какие документы нужно вести, как их заполнять и так далее.

На данный момент MISRA живёт и развивается. Например, в начале 2019 года был анонсирован The MISRA C:2012 Third Edition (First Revision) — обновлённый и дополненный новыми правилами стандарт 2012 года. Тогда же объявили о грядущем выходе MISRA C:2012 Amendment 2 — C11 Core — стандарта 2012 года, в который будут добавлены правила, впервые охватывающие версии языка Си 2011 и 2018 годов.

Не стоит на месте и MISRA C++. Как известно, последний стандарт MISRA C++ датируется 2008 годом, поэтому наиболее старшая версия языка, которую он охватывает — это C++03. Из-за этого появился ещё один стандарт, аналогичный MISRA, и называется он AUTOSAR C++. Он изначально задумывался как продолжение MISRA С++ и имел своей целью охватить более поздние версии языка. В отличие от своего вдохновителя, AUTOSAR C++ обновляется два раза в год и на данный момент поддерживает C++14. Планируется дальнейшее обновление до C++17, а затем C++20 и так далее.

Заключение

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

• сократить время на поиск и устранение ошибок;
• уменьшить вероятность критических ошибок;
• уменьшить вероятность необходимости обновления прошивок;
• контролировать общее качество кода;
• контролировать качество работы новых членов команды;
• строго следовать определённому стандарту разработки программного обеспечения;
• контролировать качество кода сторонних модулей/библиотек.

Нужен ли вам статический анализ или нет, решать именно вам!

При попытке загрузить списки пакетов из репозитория и «обновить» их с помощью apt update, пользователи наблюдают следующую картину:

404 ошибка преследует их и при попытке скачать эти пакеты заново. Сообщается, что проблема затронула вообще все версии Ubuntu, а не какие-то определённые.

В ответ на первое сообщение в треде, пользователь charliemenke отметил, что не может скачать не только Ubuntu, но и Debian-пакеты:

Проблема оказалась настолько массовой, что её обсуждение началось даже на Hacker News. Пользователь ресурса заявил, что проблема встречается не в первый раз — ранее пользователи также не могли обновить пакеты при использовании Ubuntu через Azure.

Microsoft пока никак не прокомментировала случившееся.

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

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

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

Источник: KJZZ