Главная / Кейсы / Провинциальная платформа оценки безопасности труда

Госсектор / консорциумная сеть + система аттестации

Провинциальная платформа аттестации по безопасности труда

Полностью закрыть вопрос «ведомость можно изменить» с помощью блокчейн-аттестации.

Предыстория

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

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

Для таких систем главное требование — не количество функций, а достоверность результата.

Решение

Поставлена AI-система комплексной оценки: 7 систем оценки и 9 программных модулей, раздельно по типам оценки.

При формировании каждой ведомости вычисляется отпечаток SHA-256, отпечаток записывается в цепь, а оригинал остаётся в бизнес-базе.

При проверке сравниваются только отпечатки, исходные данные не запрашиваются — доверие есть, утечки приватности нет.

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

Технический состав

В таблице ниже — технические элементы проекта, по ним клиент может проверить всё самостоятельно.

Технологический стек

Система аттестации7 систем оценки, раздельно по типам
Программные модули9 модулей, развёртываются независимо
СетьКонсорциумная сеть FISCO BCOS · 3 узла · консенсус PBFT
ОтпечатокSHA-256, вычисляется при формировании выписки
ПроверкаИнтерфейс проверки в блокчейне: достаточно сравнить отпечаток
ОтказоустойчивостьОтказ одного узла не влияет на консенсус

Результаты

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

Используемые компетенции

Обсудить похожий сценарий

01 / Ограничения

В каких ограничениях выполнялся проект

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

Эти ограничения напрямую определяют облик решения: каждая проблема в разделе «Ключевые сложности» ниже вызвана одним из них.

Четыре вида ограничений

ВремяЗапуск требовался до начала следующего аттестационного года, поэтому разработку сжали до четырёх месяцев.
Соответствие требованиямРезультаты аттестации относятся к государственным данным: их нельзя размещать в публичном облаке, они должны находиться в государственной внутренней сети.
ОбъёмОхватывает все города провинции, но условия по оборудованию и сети в них сильно различаются.
АудитПосле публикации результаты должны выдерживать проверку дисциплинарных и аудиторских органов, а любое изменение — оставлять след.
02 / Ключевые сложности

Что действительно тормозит

Это не «мы очень старались», а «как выглядела проблема, как мы её решили и какой ценой».

Как раз и навсегда закрыть вопрос «оценки можно изменить»

В прежней системе администратор мог менять оценки прямо в панели управления. Технически это несложно, но с точки зрения управления — огромный риск: при споре невозможно доказать, что текущая оценка совпадает с выставленной тогда.
Как решили: публикация строится по схеме «снимок + запись в цепь» — при выпуске формируется хеш всего пакета и фиксируется в цепи; любое последующее изменение создаёт новую версию и новый хеш, а прежняя версия не перезаписывается. Исправить ошибку можно, а сам процесс исправления отслеживаем.

Разные сетевые условия в городах

В одних городах есть выделенные сети, в других только обычный широкополосный доступ, а часть экзаменационных пунктов находится в посёлках, где связь постоянно прерывается.
Как решили: экзаменационный клиент работает по принципу «сначала локально, потом синхронизация» — ответы всё время хранятся локально, при сдаче пишутся в локальную БД с отметкой «не синхронизировано», а после восстановления сети уходят из очереди. Сводная панель региона явно помечает несинхронизированные данные, а не показывает «внешне правильные» цифры.

Пропускная способность сети не выдерживает одновременного старта экзаменов

При одновременных экзаменах по всей провинции десятки тысяч результатов появляются за полчаса, и скорость записи в консорциумную сеть становится узким местом.
Как решили: сделали асинхронно — результаты сразу пишутся в рабочую БД и возвращаются пользователю, а запись в цепь идёт через очередь с задержкой в несколько минут. Пользователь этого не замечает, а проверяющая сторона видит два явных статуса: «в цепи» и «ожидает записи».
03 / Переиспользуемые решения

Что можно напрямую перенять в других проектах

Этот раздел — для коллег по отрасли. Если вы делаете нечто подобное, эти пункты избавят вас от лишних обходных путей.

«Публикация как снимок состояния» реалистичнее, чем «запрет на правки»

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

Асинхронная запись в цепь

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

Экзаменационный клиент с приоритетом офлайн-работы

Любая система аттестации для низового звена должна исходить из того, что сеть отключится.

04 / Разбор итогов

Если бы делали заново

Рассказывать только об успехах — неискренне. Этот раздел о том, где мы ошиблись или опоздали.

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

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

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

← Все кейсы На главную