Real-Time Enterprise — основа для мудрого предприятия

Особенности интеграции

Поскольку система является комплексной, то интеграция делится на 2 составляющие: интеграция строгой технологической модели с базой данных реального времени (БДРВ) и БДРВ с системой управления производством.

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

Тестовые среды

Примечание: альтернативный подход описан в главе про Docker.

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

Стандартом индустрии является наличие трех контуров:

• dev — разработческий контур. Роль такой песочницы для разработчиков могут выполнять даже их собственные машины;
• test — контур тестирования (QA). Здесь специалисты по тестированию могут выполнять предрелизные проверки функционала;
• prod — промышленный контур. Непосредственной «боевой» контур.

Часто нужны отдельные контура для нагрузочного тестирования, опытной эксплутации, симуляционного тестирования, гостевого внешнего тестирования. В идеале каждый контур повторяет продуктивный по своим характеристикам, но имеет соответствующие среде настройки и интеграции. Управлять этим вручную довольно трудно, поэтому рекомендую использовать инструменты вроде Ansible (читайте далее), chef и др.

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

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

Автотесты

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

Для размышления

Как вы видите, за термином Real-Time Feedback скрывается изрядное разнообразие практик, и одного правильного рецепта не существует

Если вы задумываетесь о внедрении Real-Time Feedback у себя, сосредоточьтесь на следующих вещах:

Определите цель – зачем вам нужен Real-Time Feedback, какие задачи он должен решить и должен ли он быть «в режиме реального времени».

Проектируйте особенности инструмента исходя из выбранной цели.

Учитывайте опыт коллег, не вводите «повисшие в воздухе» инструменты, встраивайте их в процессы.

Продумайте, что поможет сократить число обратной связи, данной на эмоциях, необдуманно, и снизить риск, что Real-Time Feedback станет каналом сливания негатива.

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

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

Возможности реального времени вне Linux

Некоторые поставщики пытаются обеспечить работу операционной системы Linux в реальном времени за счёт её выполнения в режиме задачи на ядре реального времени (см. рис. 1). Все другие задачи, требующие детерминированного планирования, также работают на этом ядре под управлением механизма вытеснения, однако имеют более высокий приоритет, чем ОС Linux. Таким образом, эти задачи вытесняют операционную систему Linux, когда им необходимо выполниться, и уступают ей процессор после завершения своей работы.

Рис. 1. В двухъядерной модели операционная система Linux работает как низкоприоритетная задача в отдельном ядре реального времени

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

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

Увеличение трудозатрат на кодирование

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

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

Ненадёжная среда исполнения

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

Ограниченная переносимость

В двухъядерном подходе задачи реального времени являются не процессами операционной системы Linux, а потоками и обработчиками сигналов, которые написаны для узкого подмножества интерфейсов прикладного программирования (API) стандарта POSIX или, в некоторых случаях, для нестандартных API. Перенос существующего кода и приложений ОС Linux в среду реального времени становится затруднительным.

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

Недетерминированное поведение существующих приложений и драйверов в Linux

Поскольку процессы в операционной системе Linux работают за пределами ядра реального времени, их поведение остаётся недетерминированным. Планирование этих процессов по-прежнему осуществляется с помощью алгоритма «равноправия», который применяется в ОС Linux.

Ограниченные возможности проектирования

Как было сказано выше, API, поддерживаемые ядром реального времени, обеспечивают лишь часть служб API стандарта POSIX и операционной системы Linux. Таким образом, разработчики получают более ограниченные возможности проектирования, чем при использовании ОС Linux или развитой ОСРВ.

Начало начал — git

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

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

Контроль качества кода

В поддержании кодовой базы в «здоровом» состоянии кроется секрет многих успешных проектов

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

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

Sonarqube

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

Рекомендую обратить внимание на бесплатный инструмент SonarQube:

Однажды настроенный сонар может выполнять регулярные проверки качества кода в разрезе ошибок, технического долга, информационной безопасности и кода «с душком» (code smells).

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

Стиль кодирования

Практика фиксации единого стиля кодирования присуша многим сформировавшимся командам. Code guide, code style — это все примерно об одном и том же. Открывать ли фигурные скобки для одного выражения в if, переносить ли на новую строку каждый параметр функции, табы или пробелы — все эти необднозначности помогает решить договоренность команды о едином стиле кодирования. Единообразная кодовая база позволяет не только облегчить чтение кода участниками команды, но и понизить планку вхождения в проект новичкам.

Линтеры — специальный класс программ, который может помочь в неуклонном соблюдении стиля кодирования. Историческая справка: Lint это имя собственное статического анализатора языка C, «который сообщал о подозрительных или непереносимых на другие платформы выражениях». Его название стало именем нарицательным для всех программ такого рода. Сейчас линтеры существует для большинства известных языков программирования: в виде отдельных утилит, плагинов для редакторов или фичей IDE. Стиль кодирования задается некоторым конфигурационным файлом, который распространяется в команде.

Безопасность

Тема информационной безопасности была кратко затронута в главе по SonarQube. Существуют и более продвинутые статические анализаторы кода на предмет уязвимостей, например ChechMarx. Это гибкое и настраиваное ПО поддерживает все основные языки программирования и виды уязвимостей. Механизм работы примерно следующий: в коде программы отслеживается поток данных из всех входных точек (пользовательский ввод, аргументы командной строки, данные из БД) в выходные (UI, отчеты, БД) на предмет отсутствия санитайзеров. Санитайзером называется любая функция или метод, проверяющий содержимое ввода на легитимность. Если санитайзер отсутствует, то анализатор сообщает о потенциальной уязвимости. ChechMarx так же приводит полную пошаговую цепочку преобразований данных, допускающую возможную уязвимость.

Бесплатное ПО из этой же категории: wapiti, nikto

Что это вообще такое — RTO?

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

Почему использование RTO важно для отрасли в целом и нашей компании в частности?

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

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

Различия в структуре отзыва и в том, что оценивают

Есть несколько примеров, когда отзыв предполагает поле свободного ввода. Максимум – небольшие фокусировки (Яндекс, Amazon):

суперспособности (Superpowers) и зоны роста (Areas of improvement);

«Что получается хорошо» и «Что можно улучшить».

Но более распространен гибридный вариант, содержащий как поле для отзыва в свободной форме, так и набор обязательных параметров, по которым надо оценить сотрудника (Тинькофф, EPAM, Сбер, Модульбанк).

В качестве параметров компании закладывают корпоративные модели, например модель профессиональных компетенций или модель корпоративных ценностей (Сбер, Авито, EPAM), яркие маркеры взаимодействия, например желание работать с данным сотрудником дальше на одном проекте (EPAM, AxiomSL).

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

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

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

Как всё работает

Давайте на примере печи пиролиза.

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

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

Определение выборки оценивающих

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

Некоторые компании встроили в свои порталы анализ коммуникаций сотрудника за определенный период времени, на основе которого формируются рекомендации как по тем, кому данный сотрудник может дать обратную связь, так и по тому, кого ему имеет смысл включить в свой лист ревьюеров (Модульбанк, EPAM).

Планировщик с учетом приоритетности процессов

Рис. 3 Классификация планировщиков.

• Rate-Monotonic Scheduling — алгоритм со статическим приоритетом класса планирования. Статические приоритеты назначаются в соответствии с продолжительностью цикла задачи, вследствие чего более короткие циклы имеют более высокий приоритет исполнения. В худшем случае КПД загрузки центрального процессора ограничен следующей величиной.

  При числе процессов n, стремящемся к бесконечности ряд будет сходиться к ln2 ≈ 0.693147.

• Earliest-deadline-first (EDF) Scheduling динамически назначает приоритеты в соответствии с крайним сроком. Чем раньше крайний срок, тем выше приоритет и чем позже крайний срок, тем ниже приоритет. В отличие от RMS, планировщик EDF не требует, чтобы процессы были периодическими и постоянно запрашивали одно и то же количество процессорного времени на пакет. Единственное требование состоит в том, чтобы процесс объявлял свой крайний срок планировщику, когда он готов к запуску.
  Рис. 4 Планировщик EDF.
  На рисунке видим общий принцип работы планировщика. На точке 4 был замещён T1 и его место занял T2 так как его крайний срок наступал раньше, чем у T2. После отработки T3 планировщик вернулся к T1, который завершился на отметке 23.
• POSIX real-time-scheduling. Стандарт POSIX.4 определяет три политики планирования. Каждый процесс имеет атрибут планирования, который может быть выставлен в одну из трех вариантов политики.
  • SCHED_FIFO — политика упреждающего планирования с постоянным приоритетом, при которой процессы с одинаковым приоритетом обрабатываются в порядке «первым пришел — первым обслужен» (FIFO). Данная политика может иметь не менее 32 уровней приоритета.
  • SCHED_RR — политика аналогична SCHED_FIFO, но использует метод временного среза (циклический перебор) для планирования процессов с одинаковыми приоритетами. Он также имеет 32 уровня приоритета.
  • SCHED_OTHER — политика не определена и зависит от системы; может вести себя по-разному в разных реализациях.

Общее неинструментальное

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

Методология разработки

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

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

Релизы

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

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

Примечание: в GitLab есть специальная сущность — Release, однако для планирования релизов в agile-режиме можно использовать и Milestone’ы. Рекомендую изучить обе функциональности.

Документация

Ведение документации достаточно древняя практика, сопровождающая разработку. Она помогает создать общее информационное пространство проекта, позволяет участникам команды говорить «на одном языке» и облегчает погружение новых членов команды. В плане организации процесса есть опции:

• создавать документацию до разработки (функциональные требования) либо после (техническое описание);
• поручить создание отдельно выделенным аналитикам либо «догрузить» тестировщиков (Роберт Мартин рекомендует последнее).

Желательно определиться с подходом «на берегу», так как описать зрелую или легаси систему с нуля может быть довольно трудно (и нужно ли, если проект успешно обходился без нее?). Самое главное свойство документации — она должна приносить пользу.

Физически документацию можно вести рядом с кодом системы в git-репозитории (например, в MarkDown), в задачах багтрекера/agile-доски (GitLab, Jira, Redmine), в специально выделенной цiki (GitLab, Confluence), в Word-документах (в т.ч. с использованием sharepoint) и т.д

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

Эксплуатация

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

В этом случае следует с особенным вниманием отнестись к теме организации логгирования и мониторинга

Логгирование

Рано или поздно появится необходимость технологичнее управлять логами. Вероятно, логгирование в каком-то виде присутствует в коде системы. Например, пишется в файл или стандартный вывод. Возможно даже настроена ротация файлов (например, на предмет достижения максимального размера файла), и старые файлы упаковываются в архив. Пожалуй, главная проблема такого подхода заключается в том, что файлы физически находятся в конкретной среде (контуре), и разработчику их как-то нужно оттуда вытаскивать. Поиск по истории осложнен, обработка большого объема логов так же осложнена. Эти и другие сопутствующие проблемы могут быть решены с помощью специального ПО управления логами.

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

Мониторинг

Держать руку на пульсе системы помогут системы мониторинга

Самый простой сценарий использования: отправлять из приложения различные метрики (время загрузки страниц и время выполнения операций, количество неудачных логинов, состояние сборщика мусора .NET CLR и так далее, все что важно и интересно разработчикам или бизнесу) и наблюдать за ними вживую на дашборде. Стандартные метрики можно получить «из коробки» установкой пакета, непосредственно отправку метрик решают библиотеки, а для метрик бизнес-логики, конечно, потребуется дописать код системы

Из бесплатного ПО для решения задач мониторинга я бы посоветовал Grafana. Позаимствовал список особенностей Grafana из статьи:

• приятный внешний вид;
• динамичное обновление всех данных;
• визуальный конструктор;
• подключение большого количества типов источников данных (Graphite, InfluxDB, Prometheus, Elasticsearch…);
• множество способов аутентификации;
• возможность отправки Alert`ов ( Slack, PagerDuty, VictorOps, OpsGenie…);
• большое количество plugin`ов для расширения функционала.

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

Поддержка мотивации к заполнению

Самый распространенный способ поддержать интерес к начинанию – привязать отзывы к конкретным событиям, сделать их обязательной частью процесса и присылать уведомления (EPAM, ЭКОПСИ, Модульбанк, Amazon).

Геймификация тоже сохраняет свою популярность, хотя данных о долгосрочности эффекта нет (банк «Открытие», Тинькофф банк).

Возможность запросить ОС у коллег есть практически во всех рассмотренных нами кейсах (Сбер, Яндекс, EPAM).

Из более изощренных стоит отметить следующие.

Очень хорошо работает подражательное поведение: когда тебя оценили, ты сразу хочешь оценить в ответ. В BITOBE на этом эффекте построен Сервис добрых слов. Поначалу коллеги сомневались, заработает ли он, и воспользовались активностью амбассадоров, которые разослали первые открытки. Но затем использование стало лавинообразным, потому что каждый, кто получил открытку, немедленно захотел послать еще 2-3 коллегам. Один из возможных способов воплощения – сделать руководителей такими амбассадорами и обязать с определенной периодичностью давать обратную связь каждому члену команды.

Возможность добавить свой критерий, по которому тебя могут оценить (ЭКОПСИ). Как мы рассмотрели ранее, возможность кастомизировать запрашиваемый отзыв под важные для самого сотрудника параметры повышает интерес к инструменту.

Наконец, вечная классика – регулярные информационные вбросы, которые, однако, «в одиночку» почти не работают. Например, можно регулярно напоминать о внедряемой системе через вопросы аудитории: «Как работает?», «Пользуетесь ли?», «Что улучшить?» или новостные инфоповоды. Как один из удачных примеров – 30-дневный марафон обратной связи, устроенный в Национальной системе платежных карт2.

Три основные цели, для которых используется Real-Time Feedback

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

1
Для обоснования решения о размере премий/бонусов, продвижения. В этом случае feedback либо входит в performance review как составная часть, на основе которой выставляется общая оценка (Авито, Сбер), либо сам процесс сбора отзывов формально живет отдельно, но косвенно учитывается в performance review для выработки более комплексного взгляда (EPAM, Яндекс, Amazon).

2
Для развития корпоративной культуры и закрепления моделей поведения, соответствующих корпоративным ценностям (ЭКОПСИ, банк «Открытие», частично EPAM).

3
Как один из критериев для мониторинга комплексной оценки психического здоровья и благополучия сотрудников (Employee Wellbeing & Mental Health – Модульбанк, Amazon).

Миграции БД

Ок, мы разобрались с кодом системы, но что насчет объектов БД, таких как таблицы и хранимые процедуры? Очевидно, что хранение оригиналов скриптов в самой БД рано или поздно приведет к проблемам: либо они «разъедутся» между контурами, либо будет безвозвратно утрачена история, либо еще что-то в таком роде. На помощь придут миграции баз данных. Миграция это переход от одной структуры БД к другой без потери консистентности. Подход к организации миграций ограничен лишь фантазией и смекалкой разработчика, однако известное мне разнообразие подходов может быть классифицировано на:

• CREATE-подход — в кодовой базе проекта вместе с основным кодом системы хранится так же полный дамп всех скриптов БД, а именно по файлу на каждую таблицу, функцию, процедуру, вью, триггер и т.д. Внутри этих файлов находятся CREATE-выражения. Эти же скрипты в момент сборки попадают в дистрибутив (возможно в преобразованном виде). В момент установки дистрибутива с помощью специального софта (например RedGate SQL Compare или SQLPackage.exe) происходит сравнение целевой БД с эталоном базы из дистрибутива, формируется разностный скрипт, который доводит БД до целевого состояния;
• ALTER-подход — в противовес предыдущему подходу здесь хранятся только начальные скрипты создания объектов, а все изменения в них записываются как ALTER-выражения. Существует два способа организации хранения таких выражений:
  • внутри кода приложения, т.е. прямо в коде системы, а затем и в бинарнике; при запуске система проверяет версию поверх которой она ставится и догоняет ее до указанной в дистрибутиве. Пример в mattermost, ameditation;
  • снаружи в специальных файлах, например в XML-файлах в случае Liquibase (статья по теме).

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

Хорошая статья по теме: Версионная миграция структуры базы данных: основные подходы.
Особенности миграции базы в случае канареечных релизов: На пути к Canary (там же рассказано про этот тип релизов).