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

Статья будет полезна менеджерам проектов, разработчикам, тестировщикам, аналитикам и другим IT‑специалистам. Поговорим о способах выработки и применении стандартов, их влиянии на проектирование, разработку, тестирование и стабильность системы в целом. Для примера возьмем ERP CDEK, которая ежедневно обеспечивает работу десятков тысяч пользователей, нескольких сотен тысяч клиентов и позволяет нам обрабатывать до полумиллиона заказов в день.

Содержание

• Атом вместо утки. Экскурс в историю стандартизации

  • История первая. «Планёр Гимли»

  • История вторая. «Mars Climate Orbiter»

• Стандарты? Не, не слышали

• Как мы пришли к стандартизации

  • Профит

• Вам нужны стандарты. С чего начать?

• Стандарты выработаны — что дальше?

Атом вместо утки. Экскурс в историю стандартизации

Человечество задумывалось о стандартах с первых шагов современной цивилизации. В Древнем Египте при строительстве использовались кирпичи постоянного размера, а контролем соответствия размеров занимались специальные государственные служащие. Традиционные европейские системы измерения были унаследованы от древнеримских единиц, основанных на понятных каждому обывателю объектах: «палец» — дюйм, «ступня» — фут, «тысяча двойных римских шагов» — миля. Вес в древнем мире измерялся в волах, утках, зернах ячменя или пшеницы (например, один сикль равнялся весу 180 зерен ячменя).

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

В 19-м веке стандартизацией начали заниматься «в промышленных масштабах». Были предложены метрические единицы измерения сантиметр‑грамм‑секунда, появились прототипы эталонов метра и килограмма. В 20-м веке принята Международная система единиц (СИ), наиболее широко используемая в мире на сегодняшний день. В 2019 году единицы измерения СИ были полностью отвязаны от материальных эталонов и стали рассчитываться на основе физических свойств атома.

Важным этапом стало появление Международной организации по стандартизации (ISO), которая занимается выпуском стандартов. В 80-х годах прошлого века был организован Инженерный совет Интернета (IETF), оказывающий значительное влияние на современную IT‑отрасль.

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

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

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

История первая. «Планёр Гимли»

В 1983 году Boeing 767–233 авиакомпании Air Canada выполнял внутренний рейс по маршруту Монреаль‑Эдмонтон с посадкой в Оттаве. Вскоре после вылета из Оттавы, на высоте 12,5 километров в кабине пилотов прозвучал сигнал «Отказ всех двигателей». В самолете отключилось электричество и большая часть приборов на панели перестала функционировать. Пилоты взяли курс на Виннипег, но из‑за неработающих двигателей приняли решение совершить аварийную посадку на военной авиабазе Гимли. При посадке у самолета сложилась передняя стойка шасси и начался небольшой пожар, который удалось потушить. 10 пассажиров получили травмы, но к счастью, серьёзно никто не пострадал.

Эта авария произошла в то время, когда Канада переходила на метрическую систему. Наземная команда ошиблась при заправке самолета — неправильно рассчитала массу топлива (использовала коэффициент для британского имперского фунта вместо килограмма), из‑за чего вместо 20 тысяч литров было заправлено всего 5 тысяч.

История вторая. «Mars Climate Orbiter»

В 1998 году NASA проводило миссию по исследованию марсианского климата. Их космический аппарат Mars Climate Orbiter, запущенный в декабре, в течение года должен был выйти на орбиту Марса для исследования атмосферы и фотосъемки поверхности. 23 сентября 1999 года аппарат начал заходить на запланированную орбиту и после прохождения с обратной стороны планеты должен был выйти на связь. Однако больше никаких сигналов от спутника не поступало.

В ходе расследования первопричин аварии NASA сообщило, что субподрядчик в ПО аппарата использовал единицы измерения СИ, в то время как в центре управления на Земле использовались британские единицы. Предполагается, что аппарат прошел над поверхностью Марса на высоте 57 км вместо расчетных 110 км и распался в атмосфере. Данная ошибка привела к потере 327,6 миллионов долларов США, согласно оценкам NASA.

Эти истории наглядно показывают, что даже при наличии стандартов может возникать путаница между ними. А небольшие, в общем‑то, недочеты могут привести к серьезным последствиям. Хотя в большинстве случаев автоматизации бизнеса ошибки не приводят к падению самолётов или остановке работы компании, они могут привести к неудобствам для клиентов, пользователей сервисов и даже к финансовым потерям.

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

Стандарты? Не, не слышали

На момент моего прихода в CDEK, в 2019 году, в компании происходил отказ от морально устаревшей монолитной ERP‑системы, написанной на C++. Активно разрабатывалась новая версия с применением микросервисной архитектуры. На тот момент уже работало несколько десятков сервисов, написанных на Java (большая часть ядра системы), PHP (в основном витрины и интеграции) и JavaScript (фронт). При этом какая‑либо стандартизация хранения, обработки и обмена данными по большей части отсутствовала. Поэтому разработчики руководствовались в работе собственным опытом и интуицией, не применяя на практике унифицированный подход к данным.

Одной из самых распространенных проблем был подход к работе с датами и временем. Приведу небольшой список констант из уже вышедшей из употребления корпоративной Java‑библиотеки, которая использовалась для преобразования даты со временем в строку и обратно:

String SERVER_DATETIME_FORMAT = "yyyy-MM-dd HH:mm:ss";
String VIEW_DATETIME_FORMAT_STRING = "d.MM.yyyy H:mm:ss";
String VIEW_DATESHORTTIME_FORMAT_STRING = "d.MM.yyyy H:mm";
String ORACLE_DATETIME_FORMAT_STRING = "dd.MM.yyyy HH:mm:ss";
String NSPCMAIL_DATETIME_FORMAT_STRING = "dd.MM.yyyy HH:mm:ss";
String ELASTIC_DATETIME_FORMAT_STRING = "yyyy-MM-dd'T'HH:mm:ss.SSS";
String ELASTIC_DATE_FORMAT_STRING = "yyyy-MM-dd'T'HH:mm:ss";
String FILE_NAME_DATE_FORMAT_STRING = "dd.MM.yyyy-HH_mm_ss";
String VIEW_DATETIME_SHORT_FORMAT_STRING = "dd.MM.yyyy HH:ss";

Принцип использования достаточно простой: при конвертации данных (например, из строки в JSON объекте) по очереди перебирались все возможные варианты представления и при некоторой доле везения, результат записывался в типизированную переменную. При этом, например, в Java использовался безнадежно устаревший тип java.util.Date.

Легко заметить, что во всех приведённых форматах даты и времени отсутствует указание временной зоны. Фактически значение могло быть указано как в локальной таймзоне, так и неявно в UTC, по Московскому или Новосибирскому времени. Иногда формат и временная зона указывалась в комментарии к полю объекта или столбцу БД. Чаще всего приходилось выяснять это проводя натурные эксперименты, разбираясь в коде проекта. Или же искать ответственного за данный объект разработчика.

Валюты идентифицировались в ERP‑системе пятью способами: внутренний числовой идентификатор системы, уникальный идентификатор (uuid), цифровой и буквенный коды ISO 4217, причем как в верхнем, так и нижнем регистрах. Глядя на строковое поле, содержащее код валюты в произвольном обменном объекте, решительно невозможно было понять: в каком именно формате будет представлена валюта на самом деле. Это мешало не только разработке, но и анализу инцидентов. Просто представьте, что просматривая логи, вы видите 1000 единиц в валюте № 14 или 500 у.е. в валюте с идентификатором 18117342-cff4-4fa4-a2cf-c3d332c27330.

Коды языков, локалей и стран могли быть представлены в произвольном, иногда выдуманном разработчиками виде. Например, Беларусь появлялась в виде кода BR, относящегося в ISO 3166 к Бразилии. А в списке языков мог появиться казахский с кодом «kz», которого вовсе не существует в стандарте ISO 639.

Номера телефонов были полностью непригодны для автоматической обработки, поскольку даже для РФ они имели любой из префиксов «7», «+7», «8» (или не имели его вовсе). Сервисы обрастали «костылями» для обработки номеров телефонов с подсчетом цифр и подменой префиксов. Алгоритмы выглядели монструозно и были ненадёжны.

Более того, данные форматы «просочились» даже в БД, где и хранились в виде сериализованных строк, а не в виде специализированных типов. В одном объекте или таблице БД могли использоваться разные варианты сериализации одного и того же типа.

Надо ли говорить, что это значительно усложняло разработку и приводило к неожиданным багам, которые иногда обнаруживались лишь на проде…

Как мы пришли к стандартизации

Для меня, как для специалиста, более 8 лет проработавшего с банковским ПО, где использовалась строгая типизация, а для обмена данными — стандартизированные протоколы вроде SOAP, такой подход оказался весьма неожиданным. Было жаль времени и сил специалистов, которые вместо эффективного решения бизнес‑задач вынуждены тратить время на разрешение неоднозначностей нашей системы.

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

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

• Стандарт номеров телефонов — был разработан на основе ITU‑T E.164, преследует целью унификацию представления телефонных номеров (всегда указывается полностью, обязательно начинается с «+» и кода страны, не содержит разделителей);

• Стандарт валют — основным идентификатором выбран код ISO 4217 Alpha-3, который однозначен и человекопонятен;

• Стандарт финансовых и монетарных значений — с главной идеей сформулировать неотделимость суммы от валюты; в момент написания этой статьи мне встретился код, где складываются суммы из разных объектов без учета валюты!

• Стандарт локалей — за основу взято представление локали в Java (страна ISO 639-1 и язык ISO 3166-1 Alpha-2, разделенные подчеркиванием);

• Стандарт языков — согласно стандарту ISO 639-3;

• Стандарт временных зон — на основе IANA Timezone Database.

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

Профит

Внедрение стандартов:

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

• облегчило расследование инцидентов (взаимодействие между сервисами стало проще, а логи — очевиднее);

• ускорило разработку, тестирование и внедрение задач (время на выпуск бизнес‑фич сократилось до 14 дней);

• улучшило аналитику, BI (качественные исходные данные — качественный результат);

• оказало заметное положительное влияние на основной бизнес компании в целом.

Вам нужны стандарты. С чего начать?

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

Если говорить об унификации данных, в первую очередь нужно проанализировать существующие общемировые и общепринятые стандарты, например: ISO, IETF RFC, ICANN, ITU‑T. Для начального ознакомления подойдут и статьи Википедии.

Для создания некоторых стандартов легче и эффективней использовать практическую документацию. Например, для корпоративной стандартизации HTTP‑заголовков вместо исходного RFC 4229 допустимо использовать документацию MDN Web Docs, которая проще для понимания и содержит практические примеры.

К сожалению, не все общепринятые стандарты подходят для решения всего спектра задач, стоящих перед компанией. Например, стандарт ISO 3166, определяющий коды стран, основывается на бюллетене ООН и поэтому не содержит кодов непризнанных государств. В этом случае в корпоративном стандарте указывают либо кастомные, несуществующие в исходном стандарте идентификаторы, либо используют собственные (главное, чтобы это было задокументировано).

Стандарты выработаны — что дальше?

А дальше начинается самое сложное. Недостаточно просто сформулировать стандарт — нужно добиться его внедрения. Для этого существует два подхода: административный и технический.

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

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

Иногда внедрение происходит «со скрипом». В сервисах, в которых изначально использовались подходы, сильно отличающиеся от стандарта, возникает большое количество техдолга и проблем с обратной совместимостью. Обычно в таких случаях помогает разговор с командой (ура, созвон!) с аргументами, показывающими необходимость принятого решения и способы его реализации.

Конечно, стандарты применяются не только в работе с данными. Возможно стандартизировать любые бизнес‑процессы (в этом случае они к тому же проще автоматизируются), процессы разработки (взять за основу хотя бы Agile) и даже количество котиков в офисе в расчете на квадратный метр.

Если в процессе работы вы постоянно сталкиваетесь с проблемой «неоднозначности» и «неочевидности» (неважно — в данных или процессах разработки или бизнеса), то самое время подумать о стандартизации: выбрать объект и сформулировать к нему общие правила и требования. Даже если это не принесёт результата в моменте, со временем вы обязательно почувствуете накопленный эффект и положительное влияние на процессы и бизнес компании в целом.

А какие стандарты применяете вы? Как они влияют на процессы в вашем случае и приходилось ли сталкиваться с проблемами при их внедрении? Буду благодарен, если поделитесь своим опытом в комментариях.