Raiffeisendgtl

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

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

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

• Штатный командлет Get-MessageTrackingLog: удобно обрабатывать логи трэкинга;
• Утилита logparser: для логирования использует псевдо-SQL язык для поиска и работает достаточно быстро;
• Внешний SQL-сервер: для особо специфических случаев (например, анализ данных за большие промежутки времени).

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

И вот что происходит: Get-MessageTrackingLog начинает отваливаться по тайм-ауту, logparser упирается в потолок 32-битной архитектуры, а выгрузка в SQL-сервер ломается в самый неподходящий момент, не переварив многострочный exception от сервиса.

Тут на сцену выходит новый игрок стэк ELK, который специально заточен под жонглирование огромными объемами логов в разумные сроки и с терпимым потреблением ресурсов.

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

Установка

Итак, файл-архив агента filebeat можно скачать с этого сайта.

Мы выполним установку простой распаковкой содержимого zip-файла. Например, в c:\Program Files\filebeat. Затем необходимо запустить PowerShell-скрипт install-service-filebeat.ps1, который идёт в комплекте, для установки сервиса filebeat.

Теперь мы готовы начать настраивать файл конфигурации.

Отказоустойчивость

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

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

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

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

Подробнее об этом можно почитать в документации в параграфах: How does Filebeat keep the state of files и How does Filebeat ensure at-least-once delivery?

Настройка

Вся настройка выполняется в файле конфигурации формата yml, который разбит на несколько секций. Рассмотрим некоторые из них, которые участвуют в процессе сбора логов с серверов Exchange.

Блок обработки логов

Блок обработки логов начинается с поля:

filebeat.inputs:

Мы будем использовать общий инструмент сбора логов:

- type: log

Далее указываем статус (включен) и пути до папки с логами. Например, в случае с логами IIS настройки могут быть следующими:

    enabled: true    paths:- C:\inetpub\logs\LogFiles\W3SVC1\*.log- C:\inetpub\logs\LogFiles\W3SVC2\*.log

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

multiline:pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'negate: truematch: after

Имеет смысл добавить тэги в отправляемую запись, например:

  tags: ['IIS', 'ex-srv1']

И не забыть исключить из обработки строки, начинающиеся с хэш-символа:

  exclude_lines: ['^#']

Итак, блок чтения логов будет выглядеть следующим образом:

filebeat.inputs:- type: log  enabled: true  paths:- C:\inetpub\logs\LogFiles\W3SVC1\*.log- C:\inetpub\logs\LogFiles\W3SVC2\*.log  multiline:pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'negate: truematch: after  tags: ['IIS', 'ex-srv1']  exclude_lines: ['^#']

Блок отправки логов

Отдельные записи в лог файле filebeat отправляет в виде объекта json, в котором конкретная запись из лога содержится в единственном поле message. Если мы хотим как-то работать с этой информацией, нам необходимо это поле предварительно распарсить на отдельные поля. Сделать это можно, например, в logstash. Он и будет являться получателем записей из filebeat. Вот как это может выглядеть в файле конфигурации filebeat:

output.logstash:  hosts: ["logstash1.domain.com:5044"]

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

hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]  loadbalance: true 

Filebeat при обработке логов в отправляемый json помимо записи лога, которая содержится в поле message, добавляет некоторое количество метаданных, которое сказывается на размере документа, попадающего в elastic. Эти метаданные можно выборочно из отправки убрать. Делается это в блоке processor с помощью процессора drop_fields. Исключить можно, например, следующие поля:

processors:- drop_fields:fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

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

Итак, блок отправки логов будет выглядеть следующим образом:

output.logstash:  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]  loadbalance: true processors:- drop_fields:fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

Настройки логирования filebeat

Имеет смысл выставить следующие настройки логирования:

• Уровень логирования info;
• Записываем логи в файлы, расположенные по дефолту (директория logs, в директории установки filebeat);
• Имя файла лога filebeat;
• Хранить последние 10 файлов логов;
• Запускать ротацию при достижении размера 1Мб.

Финально блок настройки логирования будет выглядеть так:

logging.level: infologging.to_files: truelogging.files:  name: filebeat  keepfiles: 10  rotateeverybytes: 1048576

Итоговая конфигурация

Мы собрали конфигурацию, и теперь она выглядит следующим образом:

filebeat.inputs:- type: log  enabled: true  paths:    - C:\inetpub\logs\LogFiles\W3SVC1\*.log    - C:\inetpub\logs\LogFiles\W3SVC2\*.log  multiline:    pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'    negate: true    match: after  tags: ['IIS', 'ex-srv1']  exclude_lines: ['^#'] output.logstash:  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]  loadbalance: true processors:- drop_fields:    fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"] logging.level: infologging.to_files: truelogging.files:  name: filebeat  keepfiles: 10  rotateeverybytes: 1048576

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

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

.\filebeat.exe test config

Ещё filebeat умеет проверять сетевую доступность приёмника логов. Запускается проверка так:

.\filebeat.exe test output

В следующих частях я расскажу про подключение и дружбу Exchange с компонентами Logstash и Kibana.

Полезные ссылки

• How Filebeat works
• Log input
• Manage multiline messages
• Configure the Logstash output
• Drop fields from events
• Configure logging

Я продолжаю свой рассказ о том, как подружить Exchange и ELK (начало тут). Напомню, что эта комбинация способна без колебаний обрабатывать очень большое количество логов. На это раз мы поговорим о том, как наладить работу Exchange с компонентами Logstash и Kibana.

Logstash в стеке ELK используется для интеллектуальной обработки логов и их подготовки к размещению в Elastic в виде документов, на основе которых удобно строить различные визуализации в Kibana.

Установка

Состоит из двух этапов:
Установка и настройка пакета OpenJDK.
Установка и настройка пакета Logstash.

Установка и настройка пакета OpenJDK
Пакет OpenJDK необходимо скачать и распаковать в определённую директорию. Затем путь до этой директории необходимо внести в переменные $env:Path и $env:JAVA_HOME операционной системы Windows:



Проверим версию Java:

PS C:\> java -versionopenjdk version "13.0.1" 2019-10-15OpenJDK Runtime Environment (build 13.0.1+9)OpenJDK 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)

Установка и настройка пакета Logstash

Файл-архив с дистрибутивом Logstash скачайте отсюда. Архив нужно распаковать в корень диска. Распаковывать в папку C:\Program Files не стоит, Logstash откажется нормально запускаться. Затем необходимо внести в файл jvm.options правки, отвечающие за выделение оперативной памяти для процесса Java. Рекомендую указать половину оперативной памяти сервера. Если у него на борту 16 Гб оперативки, то ключи по умолчанию:

-Xms1g-Xmx1g

необходимо заменить на:

-Xms8g-Xmx8g

Кроме этого, целесообразно закомментировать строку -XX:+UseConcMarkSweepGC. Подробнее об этом тут. Следующий шаг создание конфигурации по умолчанию в файле logstash.conf:

input { stdin{}} filter {} output { stdout { codec => "rubydebug" }}

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

PS C:\...\bin> .\logstash.bat -f .\logstash.conf...[2019-12-19T11:15:27,769][INFO ][logstash.javapipeline    ][main] Pipeline started {"pipeline.id"=>"main"}The stdin plugin is now waiting for input:[2019-12-19T11:15:27,847][INFO ][logstash.agent           ] Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}[2019-12-19T11:15:28,113][INFO ][logstash.agent           ] Successfully started Logstash API endpoint {:port=>9600}

Logstash успешно запустился на порту 9600.

Финальный шаг установки: запуск Logstash в виде сервиса Windows. Это можно сделать, например, с помощью пакета NSSM:

PS C:\...\bin> .\nssm.exe install logstashService "logstash" installed successfully!

Отказоустойчивость

Сохранность логов при передаче с исходного сервера обеспечивается механизмом Persistent Queues.

Как работает

Схема расположения очередей в процессе обработки логов: input queue filter + output.

Плагин input получает данные от источника логов, записывает их в очередь и отправляет источнику подтверждение получения данных.

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

Настройка

Регулируется ключами в файле C:\Logstash\config\logstash.yml:

queue.type: (возможные значения persisted и memory (default)).
path.queue: (путь до папки с файлами очередей, которые по умолчанию хранятся в C:\Logstash\queue).
queue.page_capacity: (максимальный размер страницы очереди, значение по умолчанию 64mb).
queue.drain: (true/false включает/выключает остановку обработки очереди перед выключением Logstash. Не рекомендую включать, потому что это прямо скажется на скорости выключения сервера).
queue.max_events: (максимально число событий в очереди, по умолчанию 0 (не ограничено)).
queue.max_bytes: (максимальный размер очереди в байтах, по умолчанию 1024mb (1gb)).

Если настроены queue.max_events и queue.max_bytes, то сообщения перестают приниматься в очередь при достижении значения любой из этих настроек. Подробнее про Persistent Queues рассказано тут.

Пример части logstash.yml, отвечающей за настройку очереди:

queue.type: persistedqueue.max_bytes: 10gb

Настройка

Конфигурация Logstash обычно состоит из трёх частей, отвечающих за разные фазы обработки входящий логов: приём (секция input), парсинг (секция filter) и отправка в Elastic (секция output). Ниже мы подробнее рассмотрим каждую из них.

Input

Входящий поток с сырыми логами принимаем от агентов filebeat. Именно этот плагин мы и указываем в секции input:

input {  beats {    port => 5044  }}

После такой настройки Logstash начинает прослушивать порт 5044, и при получении логов обрабатывает их согласно настройкам секции filter. При необходимости можно канал получения логов от filebit завернуть в SSL. Подробнее о настройках плагина beats написано тут.

Filter

Все интересные для обработки текстовые логи, которые генерирует Exchange, имеют csv-формат с описанными в самом файле логов полями. Для парсинга csv-записей Logstash предлагает нам три плагина: dissect, csv и grok. Первый самый быстрый, но справляется с парсингом только самых простых логов.
Например, следующую запись он разобьёт на две (из-за наличия внутри поля запятой), из-за чего лог будет разобран неправильно:

,"MDB:GUID1, Mailbox:GUID2, Event:526545791, MessageClass:IPM.Note, CreationTime:2020-05-15T12:01:56.457Z, ClientType:MOMT, SubmissionAssistant:MailboxTransportSubmissionEmailAssistant",

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

filter {  if "IIS" in [tags] {    dissect {      mapping => {        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"      }      remove_field => ["message"]      add_field => { "application" => "exchange" }    }  }} 

Конфигурация Logstash позволяет использовать условные операторы, поэтому мы в плагин dissect можем направить только логи, которые были помечены filebeat тэгом IIS. Внутри плагина мы сопоставляем значения полей с их названиями, удаляем исходное поле message, которое содержало запись из лога, и можем добавить произвольное поле, которое будет, например, содержать имя приложения из которого мы собираем логи.

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

filter {  if "Tracking" in [tags] {    csv {      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]      remove_field => ["message", "tenant-id", "schema-version"]      add_field => { "application" => "exchange" }    }}

Внутри плагина мы сопоставляем значения полей с их названиями, удаляем исходное поле message (а также поля tenant-id и schema-version), которое содержало запись из лога, и можем добавить произвольное поле, которое будет, например, содержать имя приложения из которого мы собираем логи.

На выходе из стадии фильтрации мы получим документы в первом приближении готовые к визуализации в Kibana. Не хватать нам будет следующего:

Числовые поля будут распознаны как текст, что не позволяет выполнять операции с ними. А именно, поля time-taken лога IIS, а также поля recipient-count и total-bites лога Tracking.
Стандартный временной штамп документа будет содержать время обработки лога, а не время записи его на стороне сервера.
Поле recipient-address будет выглядеть одной стройкой, что не позволяет проводить анализ с подсчётом получателей писем.

Настало время добавить немного магии в процесс обработки логов.

Конвертация числовых полей

Плагин dissect имеет опцию convert_datatype, которую можно использовать для конвертации текстового поля в цифровой формат. Например, так:

dissect {    convert_datatype => { "time-taken" => "int" }  }

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

Для логов трэкинга аналогичный метод convert лучше не использовать, так как поля recipient-count и total-bites могут быть пустыми. Для конвертации этих полей лучше использовать плагин mutate:

mutate {  convert => [ "total-bytes", "integer" ]  convert => [ "recipient-count", "integer" ]}

Разбиение recipient_address на отдельных получателей

Эту задачу можно также решить с помощью плагина mutate:

mutate {  split => ["recipient_address", ";"]}

Изменяем timestamp

В случае с логами трэкинга задача очень просто решается плагином date, который поможет прописать в поле timestamp дату и время в нужном формате из поля date-time:

date {  match => [ "date-time", "ISO8601" ]  timezone => "Europe/Moscow"  remove_field => [ "date-time" ]}

В случае с логами IIS нам будет необходимо объединить данные полей date и time с помощью плагина mutate, прописать нужную нам временную зону и поместить этот временной штамп в timestamp с помощью плагина date:

mutate {   add_field => { "data-time" => "%{date} %{time}" }  remove_field => [ "date", "time" ]}date {   match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]  timezone => "UTC"  remove_field => [ "data-time" ]}

Output

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

output {  elasticsearch {    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]    manage_template => false    index => "Exchange-%{+YYYY.MM.dd}"  }}

Итоговая конфигурация

Итоговая конфигурация будет выглядеть следующим образом:

input {  beats {    port => 5044  }} filter {  if "IIS" in [tags] {    dissect {      mapping => {        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"      }      remove_field => ["message"]      add_field => { "application" => "exchange" }      convert_datatype => { "time-taken" => "int" }    }    mutate {       add_field => { "data-time" => "%{date} %{time}" }      remove_field => [ "date", "time" ]    }    date {       match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]      timezone => "UTC"      remove_field => [ "data-time" ]    }  }  if "Tracking" in [tags] {    csv {      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]      remove_field => ["message", "tenant-id", "schema-version"]      add_field => { "application" => "exchange" }    }    mutate {      convert => [ "total-bytes", "integer" ]      convert => [ "recipient-count", "integer" ]      split => ["recipient_address", ";"]    }    date {      match => [ "date-time", "ISO8601" ]      timezone => "Europe/Moscow"      remove_field => [ "date-time" ]    }  }} output {  elasticsearch {    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]    manage_template => false    index => "Exchange-%{+YYYY.MM.dd}"  }}

Полезные ссылки:

How to install OpenJDK 11 on Windows?
Download Logstash
Elastic uses depricated option UseConcMarkSweepGC #36828
NSSM
Persistent Queues
Beats input plugin
Logstash Dude, where's my chainsaw? I need to dissect my logs
Dissect filter plugin
Conditionals
Mutate filter plugin
Date filter plugin
Elasticsearch output plugin

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

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



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

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

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

Обозначения для шахматных фигур

Для начала определимся с терминами и названиями. Не все, что стоит на доске, является фигурой (англ. piece). Пешку к фигурам не относят. Но это скорее профессиональный сленг. Мы для простоты все будем называть фигурами.

Познакомимся c фигурами и запомним их вид в нашем движке.

Обозначения ходов

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

Расскажу и покажу наглядно.

Сперва пишется первая буква, обозначающая фигуру (для пешек букву не используем). Затем поле, с которого фигура совершает ход. Координата по Х обозначается буквами от a до h, по Y цифрами, начиная с 1. Очень похоже на морской бой.

Если в ходе была уничтожена вражеская фигура, то пишем x, если никто не пострадал, то будет . Затем указываем поле, на которое перешла фигура. Ну, и в конце обозначаем особые случаи: для шаха +, для мата ++, для пата =. Для превращения пешки указываем в конце тип новой фигуры.

Техническая реализация

На шахматной доске 8 на 8 клеток, всего 64. Поскольку на каждой клетке может находиться только одна фигура, то во всех современных движках шахматные фигуры хранятся в виде битовых полей в типе Long, который как раз имеет разрядность 64 бита. То есть каждая клетка получает порядковый номер от 0 до 63 и если на данной клетке есть фигура, то соответствующий бит равен 1. Но это делается для оптимизации расходов памяти и просчета большого количества комбинаций. Поскольку в моей реализации ничего такого нет, я сделал упор на читаемость кода и решил хранить фигуры в Map, где ключом является вот такой тип Point.

data class Point(    val x: Int,    val y: Int)

Data class это неизменяемый тип, автоматически определяющий такие методы, как equals и hashCode, а потому его можно использовать в качестве ключа мапы. Х расположение фигуры по горизонтали, а Y по вертикали.

Для самой фигуры определим два параметра: цвет и тип.

Цветов в шахматах всего два: белый и черный. Поэтому реализуем это в виде enum class с одним вспомогательным методом other(), возвращающим противоположный цвет (такой метод нам пригодится далее).

enum class PieceColor(val text: String) {    WHITE("white"),    BLACK("black");    fun other(): PieceColor =    when (this) {        WHITE -> BLACK        BLACK -> WHITE    }}

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

enum class PieceType(val nameEn: String,val nameRu: String,val price: Int,val notation: String,val useForPromotion: Boolean) {PAWN("pawn", "пешка", 100, "", false),KNIGHT("knight", "конь", 320, "N", true),BISHOP("bishop", "слон", 330, "B", true),ROOK("rook", "ладья", 500, "R", true),QUEEN("queen", "ферзь", 900, "Q", true),KING("king", "король", 20_000, "K", false)}

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

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

Теперь мы подошли к такому вопросу, как ценность фигур.

Ценность фигур

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

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

Движок

К этому моменту мы можем полностью хранить текущее состояние игры в виде мапы. Для этого будем использовать поле pieces класса BoardImpl, который и будет по сути нашим движком. Затем, совершая каждый ход, мы будем менять нашу мапу pieces. Все совершаемые ходы будут добавляться в историю (поле history).

class BoardImpl : Board {private val pieces = mutableMapOf<Point, Piece>()private val history = mutableListOf<HistoryItem>()// ...}

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

rnbqkbnrpppppppp................................PPPPPPPPRNBQKBNR

В этом файле 8 строк по 8 символов в каждой, т.е. 1 символ соответствует клетке на доске. Каждая фигура обозначается соответствующей буквой (например, пешка буквой P). Регистр буквы определяет цвет фигуры: верхний регистр это белые фигуры, нижний черные.

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

Генерация доступных ходов

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

interface Turn {val sourcePiece: Pieceval from: Pointval to: Pointval enemyPiece: Piece?fun execute(pieces: MutableMap<Point, Piece>)fun revert(pieces: MutableMap<Point, Piece>)}

Каждый ход содержит информацию о фигуре sourcePiece, которая этот ход совершает, ее исходную позицию from, пункт назначения to и вражескую фигуру enemyPiece (опционально, если она находится в пункте назначения). Также имеется два метода, принимающие текущее состояние доски: execute() для выполнения хода и revert() для его отмены. По сути это паттерн Команда.

Обычный ход

Этот интерфейс реализует класс NormalTurn. Его метод для выполнения хода execute() выглядит так:

override fun execute(pieces: MutableMap<Point, Piece>) {    pieces.remove(from)    pieces[to] = sourcePiece}

Просто извлекаем текущую фигуру по ключу from и помещаем на новую клетку доски по ключу to. При этом, если там была вражеская фигура, она просто перезатрется, т.е. удалится с доски.

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

override fun revert(pieces: MutableMap<Point, Piece>) {    pieces.remove(to)    pieces[from] = sourcePiece    enemyPiece?.let { pieces[to] = it }}

Ход с превращением

Также сделаем другую реализацию интерфейса Turn. Это будет специальный ход пешки, в результате которого она превращается в другую фигуру. Назовем его PromotionTurn и добавим в него одно дополнительное поле, а именно: в какую фигуру пешка должна превратиться. То есть перед этим ходом у нас имеется пешка, а после уже другая фигура. Поэтому создаем копию исходной фигуры, поменяв ее тип с помощью метода copy().

override fun execute(pieces: MutableMap<Point, Piece>) {    pieces.remove(from)    pieces[to] = sourcePiece.copy(type = toType)}

Для отмены хода нужно также учесть этот факт и восстановить исходную пешку, которая хранится в sourcePiece. Аналогично обычному ходу, восстанавливаем вражескую фигуру, если она была уничтожена.

override fun revert(pieces: MutableMap<Point, Piece>) {    pieces.remove(to)    pieces[from] = sourcePiece    enemyPiece?.let { pieces[to] = it }}

Генератор ходов

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

interface TurnGenerator {    fun getTurns(        position: Point,         pieces: Map<Point, Piece>    ): Set<Turn>}

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

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

Метод addPointIfPossible() принимает текущую позицию, относительно которой ищем ходы, состояние доски, а также смещение deltaX и deltaY относительно текущей позиции. В методе мы проверяем, не выходит ли новая точка за пределы доски, а также смотрим, нет ли в полученной точке фигуры. Если фигуры нет ход доступен. Если фигура вражеская тоже ход доступен. Дополнительно сохраняем информацию о вражеской фигуре. Ну, и если в полученной точке есть другая наша фигура, то ход недоступен.

fun MutableSet<Turn>.addPointIfPossible(position: Point,pieces: Map<Point, Piece>,deltaX: Int,deltaY: Int): Boolean {val current = pieces.getValue(position)val from = positionval to = Point(from.x + deltaX, from.y + deltaY)val otherPiece = pieces[to]return to.takeIf { it.x in 0..7 && it.y in 0..7 }    ?.let {        when {                otherPiece == null -> { // нет фигуры                this += NormalTurn(sourcePiece = current, from = from, to = to)                true                }                otherPiece.color != current.color -> { // вражеская фигура                this += NormalTurn(sourcePiece = current, from = from, to = to, enemyPiece = otherPiece)                false                }                else -> { // своя фигура                false                }        }    } ?: false}

Метод generateRectangularTurns() проверяет доступные ходы, распространяясь из исходной точки в четырех направлениях под прямым углом. То есть слева, справа, сверху и снизу. Как только где-то встретили препятствие, то дальше по этому направлению ходы не ищем. Также ограничиваем диапазон поиска с помощью параметра maxRange.

fun generateRectangularTurns(position: Point, pieces: Map<Point, Piece>, maxRange: Int): Set<Turn> {val spaces = mutableSetOf<Turn>()var left = truevar right = truevar top = truevar bottom = truefor (i in 1..maxRange) {        if (left) {        left = spaces.addPointIfPossible(position, pieces, -i, 0)        }        if (right) {        right = spaces.addPointIfPossible(position, pieces, i, 0)        }        if (top) {        top = spaces.addPointIfPossible(position, pieces, 0, i)        }        if (bottom) {        bottom = spaces.addPointIfPossible(position, pieces, 0, -i)        }}return spaces}

Эта логика поиска доступных ходов характерна для ладьи.

Далее идет еще один подобный метод generateDiagonalTurns() для поиска ходов по диагоналям также в четырех направлениях с центром в указанной точке. И тут же ограничиваем поиск по maxRange.

fun generateDiagonalTurns(position: Point, pieces: Map<Point, Piece>, maxRange: Int): Set<Turn> {val spaces = mutableSetOf<Turn>()var leftTop = truevar rightTop = truevar leftBottom = truevar rightBottom = truefor (i in 1..maxRange) {        if (leftTop) {        leftTop = spaces.addPointIfPossible(position, pieces, -i, i)        }        if (rightTop) {        rightTop = spaces.addPointIfPossible(position, pieces, i, i)        }        if (leftBottom) {        leftBottom = spaces.addPointIfPossible(position, pieces, -i, -i)        }        if (rightBottom) {        rightBottom = spaces.addPointIfPossible(position, pieces, i, -i)        }}return spaces}

Эта логика поиска подходит для слона.

Генераторы ходов для каждой фигуры

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

Для ладьи вызовем generateRectangularTurns() и укажем максимальный диапазон, в котором следует сгенерить ходы (8 клеток в каждом направлении):

class RookTurnGenerator : TurnGenerator {override fun getTurns(position: Point, pieces: Map<Point, Piece>): Set<Turn> =    generateRectangularTurns(position, pieces, MAX_RANGE)private companion object {        const val MAX_RANGE = 8}}

Для ладьи также будем генерить ходы в диапазоне 8 клеток, но с помощью метода generateDiagonalTurns().

class BishopTurnGenerator : TurnGenerator {override fun getTurns(position: Point, pieces: Map<Point, Piece>): Set<Turn> =    generateDiagonalTurns(position, pieces, MAX_RANGE)private companion object {        const val MAX_RANGE = 8}}

Для ферзя используем аналогичный подход, но будем вызывать оба утилитарных метода, объединив их в одно результирующее множество:

class QueenTurnGenerator : TurnGenerator {override fun getTurns(position: Point, pieces: Map<Point, Piece>): Set<Turn> =    listOf(    generateRectangularTurns(position, pieces, MAX_RANGE),    generateDiagonalTurns(position, pieces, MAX_RANGE)    )    .flatten()    .toSet()    private companion object {         const val MAX_RANGE = 8    }}

Для короля будет все так же, за исключением того, что MAX_RANGE будет равен 1 клетке.

class KingTurnGenerator : TurnGenerator {override fun getTurns(position: Point, pieces: Map<Point, Piece>): Set<Turn> =     listOf(    generateRectangularTurns(position, pieces, MAX_RANGE),    generateDiagonalTurns(position, pieces, MAX_RANGE)    )    .flatten()    .toSet()    private companion object {        const val MAX_RANGE = 1    }}

Для коня нам нужно проверить только те точки, до которых можно добраться ходом, напоминающим русскую букву Г (или английскую L, кому как больше нравится). Если в точке нет фигуры или есть вражеская фигура, то данная точка доступна для хода.

class KnightTurnGenerator : TurnGenerator {    override fun getTurns(position: Point, pieces: Map<Point, Piece>): Set<Turn> {    val spaces = mutableSetOf<Turn>()    spaces.addPointsIfCan(position, pieces, 1, 2)    spaces.addPointsIfCan(position, pieces, 2, 1)    return spaces    }    private fun MutableSet<Turn>.addPointsIfCan(position: Point, pieces: Map<Point, Piece>, absX: Int, absY: Int) {    this.addPointIfPossible(position, pieces, absX, absY)    this.addPointIfPossible(position, pieces, absX, -absY)    this.addPointIfPossible(position, pieces, -absX, absY)    this.addPointIfPossible(position, pieces, -absX, -absY)    }

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

Для краткости приведу только основной метод.

class PawnTurnGenerator : TurnGenerator {    override fun getTurns(position: Point, pieces: Map<Point, Piece>): Set<Turn> {    val turns = mutableSetOf<Turn>()    val current = pieces.getValue(position)

Метод getStartY()по цвету пешки определяет ее стартовую позицию по вертикали. Поэтому если текущая позиция равна стартовой, то добавляем к возможным ходам на 1 клетку больше.

val range = if (position.y == getStartY(current.color)) 2 else 1val from = position

Метод getDirectionY() в зависимости от цвета определяет направление хода пешки (приращение по вертикали), так как она может двигаться только вперед.

val directionY = getDirectionY(current.color)for (i in 1..range) {    val to = Point(from.x, from.y + directionY * i)

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

if (to in pieces) {    break} else {    turns.addTurnWithPromotionCheck(position, current, to, null)}

Наконец, проверяем клетки атаки впереди слева и впереди справа от пешки.

   addAttackPoint(position, current, 1, directionY, pieces, turns)    addAttackPoint(position, current, -1, directionY, pieces, turns)    return turns        .filter { it.to.x in 0..7 && it.to.y in 0..7 }        .toSet()}//  другие вспомогательные методы}

Объединяем все вместе

Теперь пришла пора объединить все эти классы внутри нашего движка.

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

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

fun getSpacesUnderAttack(pieces: Map<Point, Piece>): Map<PieceColor, Set<Point>> {    val spacesUnderAttack = mutableMapOf<PieceColor, MutableSet<Point>>()    pieces.entries.forEach { (position, piece) ->        spacesUnderAttack.putIfAbsent(piece.color, mutableSetOf())        spacesUnderAttack.getValue(piece.color).addAll(getTurnsForPiece(position, pieces).map { turn -> turn.to })    }    return spacesUnderAttack} 

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

fun isKingUnderAttack(pieces: Map<Point, Piece>, kingColor: PieceColor): Boolean {    val spacesUnderAttack = getSpacesUnderAttack(pieces).getValue(kingColor.other())    val king = pieces.entries        .first { it.value.type == PieceType.KING && it.value.color == kingColor }    return king.key in spacesUnderAttack}

Теперь мы можем определить метод getTurnsForPiece(), который будет отсекать все ходы, в результате которых наш король попадает под мат.

override fun getTurnsForPiece(position: Point): Set<Turn> {    val turns = UTILS.getTurnsForPiece(position, pieces)    val result = mutableSetOf<Turn>()    val kingColor = pieces.getValue(position).color    // нужно исключить каждый ход фигуры, который ставит её короля под удар    turns.forEach { turn ->            turn.execute(pieces)            if (!UTILS.isKingUnderAttack(pieces, kingColor)) {            result += turn            }            turn.revert(pieces)    }    return result}

Здесь мы получаем все множество допустимых ходов для данной фигуры. Выполняем каждый ход по очереди с помощью execute(), проверяем, не попадает ли король под мат в результате выполнения этого хода, и затем отменяем ход с помощью revert(). И так для каждого из возможных ходов, которые возвращает генератор.

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

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

Когда ход выбран пользователем или компьютером, движок получает выбранный объект Turn и просто выполняет его в методе executeTurn(), попутно проверяя состояние игры (шах, мат или пат) и фиксируя историю ходов.

override fun executeTurn(turn: Turn): GameState {    val selectedPiece = pieces.getValue(turn.from)    turn.execute(pieces)    val state = getGameState(pieces, selectedPiece.color.other())    saveTurnHistory(selectedPiece, turn, state)    return state}

Проверка состояния в методе getGameState() производится по следующей логике:

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

Дальше дело за ИИ

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

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

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



Данная статья довольно объемная и вместе с этим информативная. Поэтому надеемся на вашу вовлеченность и предупреждаем о формате tutorial.

В 2016-2017 годах мы выполнили ряд исследовательских проектов по построению децентрализованной платформы для торгового финансирования. Использовали тестовый Ethereum (Rinkeby) как базовую платформу распределенного реестра и Ethereum Swarm как средство децентрализованного обмена файлами. Кроме общих вопросов построения децентрализованной платформы испытывали возможности смарт-контрактов, применения оракулов и арбитражных смарт-контрактов. Некоторые из этих результатов есть
На базе этих исследовательских проектов претворились в жизнь
Итогом этой достаточно длительной работы стал, как говорят военные, прием на снабжение IT Райффайзенбанка штатной децентрализованной платформы R-Chain. Теперь она предлагается как элемент клиентского обслуживания для корпоративных групп разного размера.

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

Содержание

• Особенности корпоративных и межкорпоративных систем
• Общая архитектура платформы
  
  • Архитектура программных компонентов
  • Универсальный бизнес-процесс
  • Преимущества использования универсального бизнес-процесса
  • Недостатки использования универсального бизнес-процесса
  • Мониторинг сети узлов
• Эволюция использования различных технических компонентов
• Опыт исследования и эксплуатации корпоративных платформ и их дальнейшее развитие

Особенности корпоративных и межкорпоративных систем

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

• У платформы должен быть оператор юридическое лицо, несущее перед участниками ответственность за её функционирование. Вариант каждый за себя, всё решит консенсус участников и прочее, характерное для публичных блокчейн-платформ, здесь не пройдет.
• Использование платформы участником должно иметь достаточно простую юридическую обвязку, максимально близкую к существующему электронному документообороту. Поверьте, описание математических основ алгоритма консенсуса много-ранговой блокчейн-сети на 15 страницах это не то, что ожидают увидеть ваши юристы.
• Система должна удовлетворять требованиям регуляторов и обычаям документооборота по криптографии, используемой для защиты данных и подтверждения юридической значимости действий. Например, предлагая свой продукт российским клиентам, вы не раз убедитесь, что после слов мы используем ГОСТ количество вопросов заказчика волшебным образом сокращается, а его желание использовать вашу платформу пропорционально возрастает.
• Компоненты узла платформы, устанавливаемые у участника, должны хорошо ложиться в принятую в корпоративных системах сетевую сегментацию. Нахождение в ДМЗ коммерческой тайны или ключей ЭЦП, обеспечивающих юридическую значимость и всё.
• Возможность форсмажорного изменения состояния сделок в нарушение заложенной ролевой модели. Не секрет, что в жизни что-то может пойти не так пути бизнеса подчас неисповедимы, а регуляторы и решения суда делают их еще более кучерявыми, причем нередко задним числом. И в один далеко не прекрасный момент сделка может оказаться в состоянии, из которого ее нельзя по ролевой модели перевести в состояние, предписанное судьбой для этого платформа должна предусматривать соответствующие механизмы, которые позволят установить сделку в нужное состояние при условии надлежащего консенсуса участников этой сделки.

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

Общая архитектура платформы

Архитектура программных компонентов

Приложения, использовавшиеся нами в исследовательский проектах 2016-2017 годов, были написаны на основе прямой интеграции диалоговых интерфейсов с техническими компонентами распределенной платформы geth и swarm. Но, проанализировав возможности и последствия такого подхода, мы пришли к выводу о необходимости введения между бизнес-бэкендом и техническими компонентами еще одного слоя адаптера унифицированных бизнес-объектов. Данный прием относится к достаточно стандартным шаблонам построения программной архитектуры, что, тем не менее, не снижает его эффективности. В результате, программная архитектура узла нашей платформы стала выглядеть примерно следующим образом:



В такой архитектуре бизнес-приложение работает не непосредственно с абстракциями DLT-компонентов, а с неким условным универсальным бизнес-процессом (далее процесс) создает процесс, меняет состояние процесса. Приведение структуры данных универсального процесса и операций над ним к данным и операциям, используемым в DLT-клиенте, осуществляет набор компонентов, обозначенный как Зеркало бизнес-процессов. Зеркало же выполняет и обратное преобразование полученной от DLT-клиента информации, а также отфильтровывает информацию по процессам, не относящимся к участнику владельцу узла. Таким образом, на каждом узле поддерживается в синхронном состоянии база данных по бизнес-процессам, в которых этот узел принимает участие, причем в максимально удобном для бизнес-приложения формате. Бизнес-приложение взаимодействует с этой базой базой данных бизнес-процессов, получая информацию о состоянии процессов и передавая операции по изменению этих состояний.

Универсальный бизнес-процесс

Естественно встал вопрос, какими именно свойствами следует наделить универсальный бизнес-процесс, чтобы он обеспечивал, с одной стороны, максимальное использование преимуществ блокчейн-платформ, а с другой, максимальную гибкость и функциональность для применения в Бизнес-приложении. Дополнительным условием была возможность реализации выбранных свойств на большинстве из распространённых DLT-платформ, функциональные возможности которых в некоторых аспектах существенно отличаются (Ethereum/Quorum/Masterchain, Hyperledger Fabric, Corda, EOS, Waves). Базируясь на опыте своих и чужих проектов, мы пришли к следующим выводам.

Универсальный бизнес-процесс должен иметь следующий атрибутивный состав:

• Параметры процесса (вид процесса, статус, контекстные атрибуты Процесса)
• Ролевой список участников процесса
• Перечень связанных с процессом электронных документов
• Карта переходов процесса

При этом платформа должна на уровне блокчейн-компоненты обеспечивать следующие условия распространения процесса в сети:

• Полнота и целостность информации
• Конфиденциальность электронных документов за пределами круга участников процесса
• Контроль следования карте переходов процесса
• Хранение истории изменения состояний процесса

Для реализации этих возможностей были разработаны рамочные смарт-контракты с соответствующими наборами свойств и методов.

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

Параметры процесса носят условно открытый характер, так как передаются непосредственно через смарт-контракт. Для некоторых блокчейн-платформ они являются принципиально публичными (Ethereum/Masterchain), для других могут быть закрыты штатными средствами обеспечения приватности данных (Quorum приватные смарт-контракты, Hyperledger Fabric каналы и приватные данные). Наверное, важнейшим из параметров ядра процесса в нашей реализации является вид процесса, так как он несёт не только смысловую, но и функциональную нагрузку в зависимости от вида процесса адаптер DLT выбирает шаблон смарт-контракта, которым данный процесс будет представляться. Зачем это нужно? Очевидно, что существует бесчисленное количество видов сделок и столь же многообразны бизнес-процессы, обеспечивающие их реализацию. В достаточно большом количестве случаев бизнес-процессы по сути отличаются только картой переходов (с точки зрения платформы) и могут быть реализованы одним единственным смарт-контрактом, поддерживающим произвольную карту переходов (об этом ниже). Но с конкретным бизнес-процессом могут быть связаны и достаточно уникальные моменты:

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

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

В число атрибутов ядра нашего процесса входят также статус и примечание: первое это кратное описание состояния процесса (New, Canceled, Closed, OnАpproval), второе длинная строка с более подробным описание к статусу. Мы ограничиваем длину примечания где-то до 1000 символов (например, Недостаточно средств на счете), так как для передачи значительных объемов информации (тем более конфиденциальной) предназначены электронные документы, прикрепляемые к процессу.

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

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

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

• статус
• примечание
• идентификатор инициатора транзакции изменения состояния

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

Обеспечение юридической значимости очень важный вопрос, отмеченный нами в разделе Особенности корпоративных и межкорпоративных систем. Мы изначально исходили из концепции, что юридическая значимость должна обеспечиваться не средствами блокчейн-платформы, а за счет использования внешнего PKI, имеющего регуляторную поддержку или соответствующий уровень доверия у участников платформы. Грубо говоря, электронный документ, обеспечивающий юридическое обоснование ваших действий (платежный документ, контракт, требование и так далее) и прилагаемый к процессу, должен быть подписан на базе кошерного PKI (в России ГОСТ, где-то за рубежом, например, SSL или PGP/GPG ). Бизнес-приложение проверит внешнюю подпись и выполнит соответствующее действие. Или не выполнит в зависимости от результата. Кто-то скажет, что это не по-евангелистски и надо убеждать юристов в юридической значимости блокчейн-транзакций. Мы прошли много шагов этого путешествия и результат всегда был один. Впрочем, в случае с Россией сертификация Мастерчейн открывает определенные возможности в этом плане как говорится Удачной охоты!

Преимущества использования универсального бизнес-процесса

Что же в итоге нам дал такой подход?

• Расширение круга потенциальных разработчиков децентрализованных бизнес-приложений. Так как при предложенной зеркальной архитектуре от разработчика собственно бэкенд-приложения не требуется какой-либо работы непосредственно с децентрализованными компонентами, то появляется возможность привлечь к разработке без каких-либо ограничений самый широкий круг обычных разработчиков, знающих толк в необходимых продуктовых областях. Это значительно снижает сроки и стоимость разработки и повышает ее качество. В наших проектах из четырех разработчиков бэкендов трое вообще никогда ранее не работали с блокчейн-системами, а еще один имел опыт разработки на Corda, в то время как приложение работало через Зеркало с Ethereum, а затем с Quorum. С другой стороны, квалифицированные блокчейн-разработчики вместо рутинной работы по раз за разом выполняемой переделке упаковки бизнес-данных в блокчейн могут заняться действительно сложными вопросами связанными с развитием децентрализованных платформ.
• Зонирование ошибок. Не секрет, что в сложных программных системах, а децентрализованные приложения мы можем, без сомнения, отнести к таковым, время от времени что-то идет не так. Если учесть, что многие из используемых децентрализованных компонентов крайне молоды и сыры (просто в силу этой молодости и условий своего создания), то риск этого что-то не так очень сильно возрастает. И ситуация, когда на глаза изумленного пользователя выплывает багровое сообщение Ваша транзакция ёк, потому что..., никого не радует. В случае разделения программных слоев на зеркало и бизнес-приложение, зеркало перенаправляет ошибки технологической части от конечного пользователя на техническую поддержку. Это снимает ненужную психологическую нагрузку с пользователя, которому достаются только бизнес-ошибки, соответствующие его пониманию и возможности исправления. Если пользователь надлежащим образом выполнил свою часть работы, то дальнейшая забота о правильной реализации бизнес-процессов переходит с его плеч на службу технической поддержки, располагающей соответствующими навыками и инструментами. При возникновении технологических проблем у поддержки имеется несколько десятков минут, а то и часов, на то, чтобы обнаружить и исправить ошибку, и если поддержка не забывает о своих обязанностях, то пользователь может так никогда и не узнать о том, что к нему стучались страшные insufficient funds for gas * price + value или gas required exceeds allowance or always failing transaction.
• Возможность подкапотных модернизаций блокчейн-базиса. Отсутствие прямой зависимости бизнес-приложения от конкретной реализации блокчейн-базиса позволяет произвести необходимые изменения в этом базисе, не затрагивая само бизнес-приложение. А трудозатраты на бизнес-приложение, особенно с развитым диалоговым интерфейсом, может составить 75-95% от общих трудозатрат на программный комплекс. Разумеется, грамотный лид уже внутри приложения выделит интерфейсные классы и предпримет прочие меры обеспечения модульности, а подход лучше не пересобирать то, что еще работает жизнь не раз подтверждала. Таким образом, вы можете:
  
  >>> Заменить блокчейн-базис или DFS, если, например, вы изначально ошиблись в оценке производительности и сориентировались на недостаточно мощную блокчейн-платформу. Или для простоты начинали на Ethereum, но решили перейти на более взрослое решение. Или вдруг появилась новая убойная блокчейн-платформа (TON!), а вы начали чуток раньше. Или выбранный изначально компонент оказался неработоспособен в условиях конкретной сложной топологии, а вы до этого только в гомогенном облаке. Или в общем, мало ли что может произойти в период быстрого развития всех компонентов децентрализованных систем, который сейчас имеет место.
  
  >>> Создавать в качестве блокчейн-базиса сложные комбинированные решения. Например, в одном из исследовательских проектов в качестве базиса использовалось два параллельных блокчейна Ethereum это давало возможность, с одной стороны, выделить канал для высокоприоритетных неблокируемых операций, оставив пакетные и неспешные в своем канале, а с другой, просто создавало возможность кратного увеличения пропускной способности.
• Возможность смены юридически значимой криптографии. В определенной степени это подпункт предыдущего пункта. Но опыт нашего проекта с международной гарантией заставляет вынести его отдельно. И, трактуя этот опыт более широко, при трансграничном применении, особенно во многих юрисдикциях, желательно, чтобы ваша платформа не только могла менять криптографию, но и могла работать одновременно в разных криптографиях с разными участниками. Здесь, безусловно, возникает много интересных и сложных технических и юридических вопросов, например, возможность введения в состав сети доверенных узлов перешифровывания и заверения подписей будем их решать.
• Потенциальная возможность стандартизации и межсетевого обмена на уровне состояний процессов. На нынешнем этапе развития корпоративных децентрализованных приложений данный пункт, наверное, из разряда космических кораблей, бороздящих просторы Вселенной. Но плох тот минометчик, который не умеет кидать мину за холм. Выделение абстрактных объектов и их формализация неотъемлемый этап процессов стандартизации и обязательное условие широкой интеграции блокчейн-сетей. Очевидно, что одним универсальным бизнес-процессом (или его аналогом) здесь дело не обойдется сложные связи и процессы физического мира и потребности бизнес-приложений наверняка приведут к введению и других абстрактных объектов со своими наборами свойств и возможностей.

Недостатки использования универсального бизнес-процесса

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

• Где разводить бизнес-логику в хранимых процедурах БД или в коде бизнес-приложений?
• Что лучше универсальная ЭВМ или спецвычислитель?
• Вы уверены, что выбранный вами базис сохранит совместимость при последующих жизненных обновлениях? И вообще переживет следующие 2 года?

Ответ достаточно прост, если:

• У вас куча денег, времени и свободных специалистов по блокчейн-технологиям
• Вы уверены, что выбранный вами блокчейн-базис не придется менять от слова никогда
• Вам действительно надо отжать возможности платформы на 101%

Ну, тогда спецвычислитель в смысле Hyperledger Fabric или Corda с зашивкой на чейнкод и прочим вырубанием долотом в камне. Если нет думайте сами

Мониторинг сети узлов

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

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

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

• В блокчейн-базисе платформы устанавливается специальный смарт-контракт, отвечающий за сбор и распространения данных мониторинга (для краткости будем обозначать этот смарт-контракт как СКМ)
• В составе узлов сети назначается один, а лучше несколько узлов Центрального мониторинга (ЦМ), ответственных за раздачу по сети зондирующих посылок, а также сбор и анализ мониторинговой информации, поступающей с других узлов. Этот функционал может быть как основным, так и использоваться в качестве нагрузки к бизнес-функционалу узлов.
• Для блокчейн-базиса с заданной периодичность узлы ЦМ формируют зондирующие транзакции, переключающие соответствующий элемент СКМ в новое состояние это может быть просто метка текущего времени.
• Для DFS-компоненты аналогичным образом формируется и передается контрольный файл, ссылка на который также заносится в СКМ.
• Каждый из узлов сети периодически обращается к СКМ, извлекает контрольные данные и контрольный файл из DFS и проверяет актуальность контрольных меток.
• Кроме того, каждый из узлов сети передает на СКМ информацию о своем состоянии, включая:
  > контрольную временную метку
  > последнее принятое значение зондирующей метки ЦМ по блокчейн-каналу
  > последнее принятое значение зондирующей метки ЦМ по каналу DFS
  > номер последнего обработанного блока блокчейн-канала (для Ethereum-семейства или аналогичный показатель)
  > наличие ошибок в очередях операций Зеркала
  > наличие задержек в очередях операций Зеркала то есть операций, не завершенных за определенное контрольное время
  > число операций в очередях операций Зеркала
  > наличие ошибок работы с базой данных со стороны Зеркала
  > контрольная информация от бизнес-приложений

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

• При критическом отставании контрольной метки блокчейн-канала, что интерпретируется как выпадение узла из блокчейн-сети или полное нарушение ее функционирования
• При критическом отставании контрольной метки DFS-канала, что интерпретируется как выпадение узла из DFS-сети или полное нарушение ее функционирования
• При ошибках в очереди операций блокируются все последующие операции, связанные с этим бизнес-объектом (универсальным бизнес-процессом)

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

Узлы Центрального мониторинга извлекают из СКМ информацию от всех узлов сети (включая себя, кстати) и анализируют ее, позволяя своевременно обнаружить такие опасные или потенциально опасные состояния как, например:

• Полное нарушение функционирования блокчейн- или DFS-сети
• Выпадение отдельных узлов из блокчейн- или DFS-сети
• Отставание отдельных узлов в обработке данных блокчейн-канала
• Наличие ошибок в очередях обработки Зеркала
• Наличие зависания операций и чрезмерного роста очередей в Зеркале

На картинке ниже пример простейшего монитора одной из наших тестовых сетей:



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

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

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

Ибо как говорится в одной из трактовок закона Мерфи: Ошибка обычно кроется в положении, которое ни у кого не вызывает сомнения.

Эволюция использования различных технических компонентов

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

Первым был проект выпуска международной гарантии, в котором нашими партнерами были коллеги из Белоруссии март-декабрь 2018 года.

Начинали мы с конфигурации Ethereum Ethereum Swarm Крипто-Про (DLT-DFS-криптография), хорошо зарекомендовавшей себя в исследовательских проектах. Вместо использовавшейся публичной тестовой PoA-сети Ethereum Rinkeby была поднята приватная сеть Ethereum PoA и приватная сеть Ethereum Swarm. Каких-либо технических проблем изначально не выплыло, но мы столкнулись с криптографической неприятностью один из белорусских участников наотрез отказывался использовать предлагаемые нами средства криптографии, ссылаясь на локальный закон об электронном документообороте. Найти качественное решение в моменте тогда не удалось, но появилось устойчивое понимание о непростой и важной роли криптографии в успехе международных проектов.

Уже в процесс прогона контрольных сделок на реальной инфраструктуре сети (каждый участник развернул узел на своих ресурсах) были выявлены сбои в работе Ethereum Swarm потери файлов составляли на уровне 20%. Было сделано предположение, что потери связанны с проблемами, возникающими в клиенте Swarm при параллельной отправке нескольких файлов. В целом данное предположение подтвердилось: опытным путем удалось подобрать паузу между отправками в Swarm отдельных файлов в 5 секунд. При переходе к совсем боевой конфигурации сети, которая в силу особенностей примененного сетевого сегментирования в инфраструктуре Райффайзенбанка потребовала создания транзитного Swarm-узла, выявилась критическая проблема Ethereum Swarm допускал при работе через транзитный узел потерю до 30% файлов. Расслоенная архитектура и хорошая система мониторинга позволила успешно провести реальный выпуск гарантии в режиме ручной подкачки бензина, но судьба Ethereum Swarm была предрешена. Надо сказать, что заявленная способность Ethereum Swarm работать в топологиях с отсутствием прямой связи отправитель-получатель была одной из главных причин выбора его в качестве технологической основы DFS, и неспособность его надежно работать в таком режиме создала массу проблем.

Следует отметить, что приватная сеть на базе Ethereum в этом проекте порадовала своей восстанавливаемостью. График проекта предполагал, что закрытие выпущенной гарантии будет произведено через 3 месяца после ее выпуска, и на время этой паузы некоторые из участников остановили свои узлы. Тем не менее, при повторном запуске сеть без каких-либо танцев с бубнами за 1 день восстановила свою целостность, и операция закрытия гарантии прошла без каких-либо нареканий.

Следующим проектом стало создание внутригрупповой сети для Группы Компаний Аскона сентябрь 2018 текущее время.

С учетом опыта проекта по международной гарантии в качестве технологической основы для DFS была выбрана IPFS (InterPlanetary File System). Она нормально отрабатывала отправку файлов в параллель, и ей не потребовались специальные подстройки режимов. Единственным, пожалуй, слабым местом IPFS является невозможность (оговоренная!) работать в транзитных топологиях. При построении сетей с большим числом участников реализация каждым из них полной звезды доступов каждого к каждому является, мягко говоря, организационной проблемой. С другой стороны, все участники реализуют доступ между собой и опорными узлами оператора. Поэтому для организации беспрепятственной раздачи файлов был реализован следующий механизм:

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

Таким образом, проект Аскона стартовал в конфигурации Ethereum IPFS Крипто-Про.

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

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

Решением оказался Quorum практически, родной брат Ethereum. Число доработок в Зеркале было минимальным, бизнес-приложение, понятно, доработок вообще не требовало.

На текущий момент переход на Quorum принес только плюсы:

• Использованный Raft-консенсус исключает форки
• Отсутствие пустых блоков уменьшает размер цепочки

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

Единственным, пожалуй, неприятным свойством Quorum является возможность генерации при рестарте после длительной паузы мега-блока размером в несколько мегабайт, который просто заклинивает адаптер DLT при попытке разгрести его содержимое. Но, строго говоря, служба поддержки не должна спать настолько долго.

В итоге всей этой драматической эволюции мы пришли к конфигурации Quorum IPFS Крипто-ПРО, которую сейчас и используем на внутреннем рынке РФ.

Возможно, кто-то задаст закономерный вопрос: А что же, раньше вы про Quorum не слышали, что ли?. Слышали и про Quorum, и при Hyperledger Fabric, и про EOS. Автор данной статьи даже посещал первый воркшоп на русском языке по Corda осенью 2017 года. Наверное, специально для умного ответа на такие вопросы Гегель и придумал свою Диалектику. Начинавшая исследования в 2016 году небольшая команда имела хороший опыт разработки диалоговых приложений под Windows, а публичный Ethereum (тестовый понятно) имел наименьший порог входа из блокчейн-платформ. А так как мы были заинтересованы в проведении исследований именно по блокчейн-тематике, а не в ковырянии разных докеров, без которых запустить взрослые Quorum или Hyperledger Fabric просто нереально (да и не на всех виртуальных Windows-платформах возможно), то и выбор был очевиден. По мере того как результаты исследований стали привлекать внимание бизнес-подразделений банка и его партнеров, появилась возможность расширить команду, поручить сапоги сапожникам, а пироги пирожникам, разжиться Linux-серверами и так далее. И, естественно, никто не выбрасывал наработанные решения, пока они сохраняли потенциал развития. Диалектика и Эволюция.

Опыт исследования и эксплуатации корпоративных платформ и их дальнейшее развитие

Автор данной статьи принимал участие в достаточно большом числе блокчейн-проектов, проведенных в Райффайзенбанке, в Ассоциации ФинТех и кое-где еще и в качестве разработчика, и в качестве эксперта по децентрализованным платформам. Часть из них была чисто исследовательскими, часть завершилась пилотами, некоторые доросли до достаточно крупных промышленных сетей в несколько десятков узлов.

Какие же основные выводы можно сделать из всего этого опыта?

1. Существует определенное многообразие блокчейн-платформ, весьма сильно различающихся в своих потребительских качествах:

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

Поэтому говорить о том, что какая-то из платформ окажется абсолютно доминирующей, я думаю, нельзя. У каждой есть свой круг потенциальных пользователей и задач, где ее использование наиболее рационально и рентабельно. Это касается и Ethereum, и Quorum, и Hyperledger Fabric, и Corda. Здесь как и с языками программирования только Вася и Петя, знающие по одному языку будут до одури спорить о том, что лучше плюсы или жаба. А Семен Петрович и Альберт Иванович, знающие их по десятку, будут мирно рассуждать когда лучше плюсы, а когда жаба.

2. Несмотря на то, что некоторые из DLT-платформ (например, Hyperledger Fabric и Corda) предоставляют возможность передачи больших элементов данных по сути файлов, скорее всего, блокчейн-базис с механизмами смарт-контрактов и функционал передачи файлов будет оставаться разделенным. Это связано со следующими моментами:

• Специализированные децентрализованные файловые системы существуют дольше, лучше отлажены и на текущий момент эффективнее справляются с этой задачей по сравнению с аналогичным функционалом DLT-платформ. Мы проводили оценочные эксперименты. По их результатам при использовании Hyperledger Fabric и Corda файлы размером более 2M имеют высокую вероятность застрять в канале, в то время, как IPFS без проблем пробрасывает и 100M. А если ваш бизнес-кейс предполагает движение каких-либо неформализованных документов типа pdf (контрактов, договоров и прочее), то 50M минимум, к которому вам надо готовится.
• Такой подход позволяет достаточно эффективно физически развести блокчейн-канал и канал передачи файлов, что весьма актуально для систем с высоким смешанным трафиком (транзакции + документы), тем более, что операционный приоритет транзакций обычно более высок.
• В качестве альтернативы децентрализованным файловым системам неплохо смотрятся облачные файловые хранилища, например, стандарта S3. Они, конечно, несколько подрывают истинную децентрализованность, но с точки зрения безотказности вполне вписываются в распределенные сети, а по скорости обмена и надежности даже превосходят DFS. Тут возможно появление даже неких гибридных решений.
• Если смотреть немного вдаль, на возможную интеграцию между собой отдельных корпоративных сетей, особенно построенных на разных блокчейн-базисах, то выделение файлового канала потенциально упрощает решение.

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

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

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

Встретимся 15 декабря и вместе посмеёмся над историями скрам-мастеров, помня, что в каждой шутке есть своя мораль. В программе вредные советы от Сбера, МТС, Альфа-Банка, ОТП и Райффайзенбанка.

Присоединяйтесь к нам!

О чем будем говорить

Что бывает, когда 8 шапок скрам-мастеравстречаются с реальной жизнью!

Наташа Епейкина, Райффайзенбанк

От создателей это не на нашей стороне и в Jira этого не было.

Фейлы скрам-команд, и что можно с этим сделать

Росянок Виталий, МТС

Фейлы, с которыми встречаются все скрам-мастера. Обсудим тривиальные косяки скрам-команд в комичной форме, увидим себя и разберём варианты решений.

Молотки, гвозди и парное программирование

Арсений Кельдышев, Райффайзенбанк

История о нанесении добра и несусветной пользы.

Как перестать волноваться и начать жить СМу?

Екатерина Шевченко, ОТП Банк

На что похожи взаимоотношения СМ и команды? Два кейса из реальной практики.

Сейчас смешно, а раньше было поучительно

Никита Щербаков, Сбер

Важные истории из жизни СМа и команды, над которыми сейчас можно посмеяться.

Самые Большие Ошибки Скрам-мастера

Сергей Макаркин, Альфа-Банк

Как гарантировать провал Agile и привить сотрудникам отвращение к Scrum.

>>> Начнем митап в 19:00 (МСК).
Регистрируйтесь, чтобы получить ссылку на трансляцию: письмо придет вам на почту.

До встречи онлайн!

Впервые о книге Фредерика Брукса я услышал лет десять назад, ещё учась в универе. Её настоятельно советовал почитать наш научный руководитель. Как часто бывает в таких случаях, когда кто-то вам советует что-то почитать, то вы вежливо говорите нечто вроде да-да, в скором времени, непременно этим займусь, заносите очередной пункт в свой grow list (в лучшем случае) и благополучно об этом забываете.



Через пару лет я вернулся к этой книге и наконец с ней ознакомился. К тому моменту у меня уже было несколько лет работы в IT-индустрии. И когда я начал читать, то удивился, насколько книга, написанная в 1975, да ещё и в сфере разработки ПО, по-прежнему актуальна!

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

Пара слов об авторе книги

Фредерик Брукс был менеджером проекта по созданию IBM OS/360 (группа операционных систем, разработанных IBM для мейнфреймов System/360). Для ускорения разработки он предпринял попытку привлечь ещё больше разработчиков, но решение это оказалось фатальным. Чтобы никто более не наступал на те же грабли, Брукс впоследствии написал серию очерков, которую мы теперь знаем как Мифический человеко-месяц. Считается, что каждому менеджеру проекта следует ознакомиться с этой книгой.

Высокая кухня требует времени

Именно такой эпиграф предваряет вторую главу книги, а начинается она со слов:

Все программисты оптимисты.

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

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

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

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

Брукс проводит наглядную аналогию между приготовлением еды и разработкой ПО:

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

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

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

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

Поскольку Брукс сам погорел на этом при разработке IBM OS/360, он сформулировал такой закон:

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

Хирургическая бригада

Третью главу Брукс начинает со следующего утверждения:

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

Продолжая эту мысль, он говорит, что лучше всего небольшая высококлассная команда (не более 10 человек) чем меньше умов, тем лучше. На ваш взгляд, каков максимально допустимый размер команды?

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

Брукс даже приводит примерный состав команды, расписывая роль каждого её участника.

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

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

Эффект второй системы

Наверняка многим из вас приходилось работать с такими коллегами (а то и самим бывать в такой ситуации), когда уже более-менее опытный разработчик пытается предусмотреть наперёд все варианты дальнейшего развития системы и заранее перезаложиться всевозможными абстракциями, усложняя читаемость кода и повышая его сложность? Брукс называет это эффектом второй системы.

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

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

Тут сложно что-либо добавить или опровергнуть. Я с автором полностью согласен. Решением данной проблемы является, на мой взгляд, принцип KISS (keep it simple, stupid). Потому что в современных реалиях любые попытки угадать дальнейшее развитие системы являются делом неблагодарным.

Пилотная установка

В этом мире нет ничего постоянного, кроме непостоянства.

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

Планируйте выбросить первую версию вы всё равно это сделаете.

Как вы уже догадались, речь идёт об MVP (minimum viable product). Это некий прототип, позволяющий проверить ту или иную гипотезу бизнеса. Продолжая предыдущую тему, на этапе MVP следует выключить внутреннего перфекциониста. А уж если результат эксперимента окажется положительным, тогда получится быстрее с нуля написать вторую версию как положено.

Два шага вперёд и шаг назад

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

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

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

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

И грянул гром

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

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

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

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

Самодокументированные программы

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

Однако есть и другая точка зрения на этот вопрос. Например, Мартин (Роберт, а не Джордж), автор книги Чистый код, утверждает, что комментарии это зло. Даже будучи среди исходного кода они всё равно могут стать неактуальными. Не трать время на написание комментариев, говорит Мартин. Вместо этого он предлагает более тщательно подходить к процессу именования переменных, методов и классов. Если всё делается правильно, то и необходимость в комментариях отпадает. А какой точки зрения придерживаетесь вы, документируете ли свой код непосредственно в исходниках?

Модель инкрементальной разработки

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



Далее мы реализуем любую из этих заглушек и наша система, не меняя своей структуры и не останавливаясь, начинает уже делать что-то полезное. Важно отметить, что на каждом этапе у нас есть работающая система. Это ли не принцип непрерывной интеграции, он же CI (continuous integration)?

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

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

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

Тут хотелось бы просто привести цитату Брукса, в которой он иронизирует над самим собой. Он описывает случай, произошедший в самолёте:

Незнакомец, сидевший рядом со мной, читал Мифический человеко-месяц, и я ждал, как он отреагирует словом или знаком. Наконец, когда мы вырулили к выходу, я не выдержал:
Как вам эта книга? Рекомендуете?
Гм! Ничего такого, чего бы я уже не знал.

Я предпочёл не представляться.

Действительно, зачем переиздавать книгу, которой вот уже 45 лет и которая посвящена такой динамично развивающейся отрасли, как разработка ПО? Весь материал, который я привёл выше, показывает, что многие вопросы, рассматриваемые в книге, актуальны до сих пор. Да, у нас есть scrum, agile, стори-поинты, но если присмотреться, то все новое забытое, но проявившее себя вновь, старое.

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

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

Присоединяйтесь к нам!

О чём поговорим

Микрофронтенд или Как всё разбить на маленькие кусочки и собрать вместе

Дмитрий Григоров, Газпромбанк

О спикере: Тимлид команды интернет-банка, девелопер, спикер и просто хороший специалист по реакту. Более 5 лет в разработке и продвижении продуктов.

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

И остаётся один вопрос: Как можно вынести части, которые можно переиспользовать и отдать другим командам? Об этом мы и поговорим.

Как микросервисная архитектура помогает развитию сотрудников внутри компании

Сергей Огородников, Райффайзенбанк

О спикере: Профессионально разрабатывает на C# с 2005 года, пришёл в.Net за пару месяцев до того, как подвезли generics. Сейчас работает старшим разработчиком в Райффайзенбанке в команде, занимающейся разработкой продуктов для HR. Интересуется DDD, software architecture, разработкой анализаторов кода, немного ФП.

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

Начнем митап в 19:00 (МСК)

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

До встречи онлайн!

Присоединяйтесь 10 декабря к онлайн-митапу сообщества System Analysis Райффайзенбанка. Обсудим тему Low-Code/No-Code: как технологии совершают революцию в создании корпоративных приложений и как использовать эти технологии для решения задач аналитика. Еще сразимся с хаосом узнаем, как структурировать изменения с помощью моделей.

До встречи онлайн!

О чем будем говорить

Борьба с хаосом с помощью моделей

Евгений Асламов, независимый эксперт

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

Low-Code/No-Code: революция создания корпоративных приложений (наших дней)

Алексей Трефилов, ELMA

О докладе: Сегодня создание конкурентных преимуществ практически немыслимо без цифровизации. Еще вчера разработка корпоративных приложений была трудоемким и долгим делом решения стоили дорого, а сроки их разработки приводили к релизу не всегда актуальных систем. Сегодня технологии Low-Code/No-Code совершают революцию в создании внутренних приложений. Аналитики и бизнес-пользователи могут создавать решения быстро и без помощи программистов. Алексей расскажет о том, что это за технологии, на что они способны сегодня и в чем, собственно, дисрапт.

Low-Code/No-Code: как стать частью революции

Анна Казаченко, Райффайзенбанк

О докладе: В своем докладе Анна подробно расскажет о том, как можно использовать технологии Low-Code/No-Code для решения задач аналитика.

Активничаем в сообществе в Telegram, присоединяйтесь: @Open_SA_Community_Raif

Начнем митап в 18:30

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

Первая онлайн-встреча сообщества DB & DWH Райффайзенбанка пройдет 15 сентября. Присоединяйтесь к нам, чтобы узнать про автоматизированное тестирование методом черного ящика и про переход на ETL-as-Service при помощи Informatica Power Center.

О чем будем говорить

Автоматизированное тестирование методом черного ящика в хранилище данных

Панюшкина Юлия и Колесников Дмитрий, Райффайзенбанк

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

Перевод банковских процессов на ETL-as-Service при помощи Informatica Power Center

Александр Попов, ОТП-банк

Спикер расскажет о том, как планируется из монолитной платформы Informatica PowerCenter сделать полноценное общебанковское средство разработки ETL.

>>> Начнем митап в 16:00 (МСК).

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

Онлайн-митап Scrum Community Райффайзенбанка пройдет 13 октября, приглашаем вас присоединиться! Вместе поговорим о зрелости организации: как её измерять и что потом с этим делать. Рассмотрим менеджмент 3.0, agile manifesto 2.1 и варианты диагностики и работы с помощью спиральной динамики.

О чем будем говорить

Maturity starts when the drama ends

Наташа Епейкина, Райффайзенбанк
Мария Кручинина, Райффайзенбанк
Антон Зотин, независимый коуч, ментор и консультант по Agile

Что такое maturity, и что с ней делать

Maturity и спиральная динамика для хардкорщиков

Management 3.0 на все случаи жизни от Антона Зотина:

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

>>> Начнем митап в 18:00 (МСК).
Регистрируйтесь, чтобы получить ссылку на трансляцию: письмо со ссылкой придет вам на почту. И не забывайте знакомиться и общаться чат Scrum Community @ Raiffeisenbank в телеграме.

Мы вас ждем, до встречи online!

Приглашаем на открытый QA meetup, он пройдет 28 октября. Поговорим об инструменте Cypress и посмотрим его в действии, а также обсудим роль оркестраторов бизнес-логики в корпоративных приложениях.

Подключайтесь к нам!

О чем будем говорить

Как мы начали использовать Cypress в тестировании и не прогадали

Марина Парусникова, Райффайзенбанк

О спикере: старший тестировщик в Райффайзенбанке. Имею опыт в тестировании более 6 лет. В начале карьеры занималась ручным тестированием десктопного приложения, написанием юнит-тестов, разработкой эмулятора. В Райффайзенбанке погрузилась в мир автоматизации тестирования веб-приложений, испробовала BDD и TDD на практике, занималась нагрузочным тестированием. Люблю выстраивать удобные процессы в команде, считаю особенно ценным достижение синергии в работе тестировщиков и разработчиков.

О докладе: Cypress набирающий известность фреймворк для автоматизации тестирования веб-приложений. Можно ли им полностью заменить автоматизацию на Selenium+Cucumber? Как начать тестировщикам использовать Cypress для автоматизации тестов? Поделюсь опытом в выступлении.

Оркестр на изоляции: автоматизируем тесты Camunda

Денис Кудряшов, Леруа Мерлен

О спикере: Прошёл стандартный карьерный путь (из тестирования в разработку) наоборот. Ушел из разработки в тестирование более 3-х лет назад, сейчас занимаюсь автоматизацией. Как-то раз тестировал сайт и случайно нашел уязвимость в Яндексе.

О докладе: В докладе речь пойдёт о роли оркестраторов бизнес-логики в корпоративных приложениях. Я расскажу о том, какие системы и каким образом используются в Леруа Мерлен. Мы исследуем систему управления бизнес-процессами Camunda с точки зрения тестирования реализаций BPMN схем, а также поговорим об инфраструктуре тестовых окружений (как мы понимаем и поднимаем их у себя в Леруа). И всё это с примерами!

>> Начнём митап в 18:00 (МСК).
Регистрируйтесь, чтобы получить ссылку на трансляцию: письмо со ссылкой придет вам на почту. Мы вас ждем, до встречи online!

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

Ждем вас онлайн!

О чем будем говорить

Cypress для интеграционного тестирования. Зачем? Как?

Светлана Голдобина, Райффайзенбанк

О спикере: Старший тестировщик в Райффайзенбанке, команда Cash Management. Опыт в автоматизации тестирования больше 3-х лет в крупных банках. За карьерный путь успела поработать как с BDD фреймворками, в том числе Akita, и поучаствовать в ее развитии, так и перейти полностью на сторону тестирования на стеке разработчиков JavaScript/TypeScript, Java + Spring.

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

О докладе: В нашей команде писали тесты в BDD стиле на русском языке (Selenium/Selenide + Cucumber + Java). Казалось бы, куда еще проще и прозрачнее для команды? Однако, как только мы лишились нескольких QA, и разработчикам пришлось писать и дорабатывать тесты, наш инструмент стал стоппером в тестировании, и BDD тут ничем не помог. В докладе расскажу, как мы опустили тестирование на дно и начали его восстанавливать.

Как мы добились нуля ошибок по итогам интеграционных тестов

Максим Плавченок, Bercut

О спикере: Работаю в компании Bercut с 2002. Начинал карьеру в телекоме: прошёл путь от сменного инженера до руководителя направления интеграционного тестирования. Был разработчиком, тестировщиком, менеджером продукта. Люблю заниматься тем, что приносит проблемы (и решать их), поэтому и пришёл в тестирование.

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

У нас ушло на это 2 года, и это получилось за счёт улучшений по нескольким направлениям: инструменты, экспертиза, документация, работа с заказчиком, команда. Улучшения различались по значимости: знать специфику и процессы заказчика важно, перейти к новой шкале оценки сложности задач опционально, а работать с мотивацией команды критически важно.

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

>>> Начнем митап в 18:00 (МСК).
Зарегистрируйтесь, чтобы получить ссылку: письмо с трансляцией придет на почту всем участникам.

До встречи онлайн!

Ждем вас на онлайн-митап Acceleration Community 28 января: поделимся опытом смены инструмента в большой организации, вместе познаем искусство удерживать баланс между бизнес-ценностями и техническим долгом, а также узнаем, какой он современный подход к безопасной разработке в крупных IT-компаниях.

Регистрируйтесь и присоединяйтесь к нам!

О чем поговорим

Из зоопарка в лунапарк, или как мы всем банком Gitlab внедряли

Сергей Куприянов, Райффайзенбанк

О спикере: Сергей product owner команды backend tools, части acceleration team. Команда разрабатывает и внедряет инструменты для разработчиков внутри Райффайзенбанка. Сергей пришел в банк тестировщиком, работал в команде финансов. Сейчас занимается, инфраструктурными проектами, DevOps, CI/CD процессами.

О докладе: Казалось бы, совсем недавно мы избавились от зоопарка инструментов и перешли на стек Atlassian и Bamboo, в частности, но счастье оказалось недолгим наши запросы возросли, и мы встали перед необходимостью выбора нового инструмента Ci/Cd.

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

Искусство канатоходца бизнес и искусство

Андрей Юмашев, ЛитРес

О спикере: CTO по информационному обеспечению в ЛитРес. Более 15 лет в IT, последние несколько лет евангелист DevOps-философии, специалист по построению коммуникаций и процессов в IT-части бизнеса.

О докладе: Мы всегда знаем, что нам делать. То, что делается это исключительное искусство. Его сложно загнать в рамки метрик и отчётов. Расскажу, как грамотно удерживать баланс между бизнес-ценностями и техническим долгом и что это вообще такое. И как наложить метрики на деятельность и выстроить плавные и гибкие процессы, понятные руководству компании.

Cовременный подход к безопасной разработке в крупных IT-компаниях

Владимир Пазухин, Ernst & Young (EY)

О спикере: Владимир менеджер компании Ernst & Young, с 2013 года занимается выполнением проектов в области кибербезопасности и специализируется на тестировании защищенности приложений, анализе безопасности исходного кода, анализе рисков информационных систем и совершенствовании процессов кибербезопасности. Область интересов: интеграция контролей и тестов информационной безопасности в процессы DevOps, анализ уязвимостей современных онлайн-сервисов и мобильных приложений, а также автоматизация выявления подобных уязвимостей.

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

>>> Начнем митап в 18:00 (МСК).
Регистрируйтесь, чтобы получить ссылку на трансляцию: письмо придет вам на почту.

До встречи online!

Если помните, недавно мы публиковали анонс хакатона RAIFHACK, который прошел онлайн 14-15 ноября совместно с командой Russian Hackers. Казалось бы, это обычный хакатон. Но на нем было все: отрицание, гнев, торг, депрессия, принятие, шутки и, конечно же, мемасы.

Основной повесткой RAIFHACK было создание решений для малого и среднего бизнеса в двух треках:

• Знай клиента и конкурента это об использовании данных. Участники разрабатывали продукт в парадигме Data as a Service на основе анонимизированных клиентских данных.
• Платить легко это об использовании API системы быстрых платежей. Здесь предлагали полезные для бизнес-клиентов решения на основе API СБП от Райффайзенбанка, которые упростят работу с покупателями.

Про темы и сам хакатон

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

Мы отслеживаем запросы клиентов в этой сфере и стараемся тут же внедрять для них новые услуги. Речь как о стандартизированных, так и о гибких ИТ-решениях. Например, мы стали лидером внедрения системы быстрых платежей (СБП) в свои продукты. Это одно из первых решений на российском рынке, которое позволяет выставлять счета покупателям прямо со смартфона продавца.

Если говорить о продуктах в парадигме Data as a Service, то предыстория такая: в 2019 году после многочисленных кастдевов с партнерами программ лояльности, мы получили следующую картину: бизнес остро ощущает нехватку объективной информации о своих клиентах в реальном конкурентном окружении.

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

Формат, регистрации, таймлайн

В организации RAIFHACK мы решили не идти путем классического хакатона, когда команды получают задачу и 24-48-72 часа на ее выполнение. Нам хотелось, чтобы участники изначально погрузились в сам продукт. Поэтому CJM был таким:

• зарегистрироваться командой;
• ознакомиться с задачей трека и прислать свою идею продукта;
• пройти отбор на финал;
• получить на финале датасет и доступ к API, допилить продукт и представить демо.

Тема хакатона вышла узкой, но мы получили 900+ индивидуальных регистраций, 100+ командных решений на этапе отбора, а в финал вышло 28 команд.

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

Получив на отборе 60 идей в треке DaaS и 51 в СБП, мы приступили к оценке заявок. Решения смотрели менторы треков: как минимум продуктовый и технический + дополнительные. Уже на этапе отбора мы оценивали, насколько реализуемо решение например, в треке DaaS огромный вес имела DS-составляющая, отчего многие команды получили в этой части очень низкий балл. Эти оценки вызвали много гнева. Как и то, что некоторые проекты были просмотрены бОльшим количеством менторов, другие меньшим, и те, что вызвали более живой интерес, получили и рейтинг повыше. В целом это соответствует реальной ситуации, когда стартап презентует идею инвестору.


Не обошлось без эмоциональных реакций :)

Не будем делать вид, что мы белые и пушистые у нас тоже случился косяк. Итоги подводились в спешке и в одной из таблиц банально уехала формула. В итоге мы выкатили результаты с ошибкой и справедливо заметили, что работа сделана в стиле: тяп-ляп и в продакшен!. Спасибо участникам, что это заметили, хоть и стыдно. Так мы добрали в финал категории СБП еще 5 команд.

По поводу системы оценок готовых решений дискутировать можно вовсе бесконечно. У нас одно видение, у некоторых участников другое. Гнев породил собой гневные комментарии, мемасы и демотиваторы (sic!).



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



Несмотря на все, финал все же состоялся и прошел 14-15 ноября. Расписание было крайне плотным, и мы ожидали, что от одной до трёх команд просто не дойдут до конца это нормально для подобных хакатонов. Удивительно, но у нас до конца дошли все!

Хакатон, кодинг и хардкор

Расписание хакатона жесткое, датасет огромный, пилить приходилось немерено, а еще целых 3 точки контроля менторами и не протестированный командами API. Участникам приходилось подключаться и сдавать, что есть, иначе команда снимается с дистанции.

Все чек-поинты мы разбили на 3 этапа:

• идея и план реализации;
• черновая версия прототипа;
• правки прототипа + обсуждение презентации.

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

Сетка чек-поинтов со стороны менторов выглядела примерно так:



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

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

Демо и питчи

До демо добрались все. В этот раз мы решили не делить выступления и слушали все команды в едином потоке. Это был эксперимент, и он оказался не самым удачным, это правда. Сами признаем: 28 презентаций подряд это перебор. Мы получили пять предложений все же делить выступления на этапы, но большинству смотреть чужие проекты было довольно интересно.

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

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

Кто же выиграл? Далее мы расскажем о проектах, которые одержали победу в рамках своих направлений.

Победитель DaaS команда DS29

Суть проекта: сервис группы подписок от бизнес-клиентов банка с формированием предложения на основе транзакций клиентов.

Задача проекта: разработать продукт в парадигме Data as a Service на основе данных о клиентах и их транзакциях.

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



Здесь можно скачать презентацию проекта.

Я ожидала получить фидбек на первоначальную идею, проработать ее и, получить мерч и поесть :) Конечно, мы хотели выиграть и сделали все, чтобы этого достичь. Здорово, что нам удалось Анастасия Кишкун, тимлид и аналитик команды.

Очень понравилась гибкость в работе с менторами: на чек-поинтах можно было подвинуть время звонка, на наши вопросы оперативно отвечали в чате, и это очень помогало в работе, Алиса Аленичева, Data Scientist.

Победитель СБП команда LIFE Laboratory

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

Задача проекта: разработка системы быстрых и удобных платежей через СБП банка с возможностью использования NFC-модуля смартфона устройства, которое всегда под рукой.

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



Как решили задачу: реализовали приложение NFC for SFP, которое получает от оператора QR-код с вшитыми для платежа данными. Клиент получает по NFC данные, которые позволяют выбрать свой банк-приложение, после чего остается лишь нажать кнопку подтвердить оплату. В обычной ситуации курьеру приходится брать с собой платежный терминал; большинство моделей таких устройств достаточно тяжелые и неудобные, плюс дорогие. Гораздо проще использовать смартфон с модулем NFC.

Для проекта разработано как само приложение, так и веб-сервис, вернее, веб-интерфейс приложения. Веб-интерфейс приложения предназначен для оператора, на котором формируется заказ клиента, генерируется QR-код для оплаты, после чего все это передается курьеру.



Здесь можно скачать презентацию проекта.

От хакатона ожидали купончики по 500 рублей на еду в Яндексе, нудные и долгие чекпоинты, и сомневались в менторах. Но получилось, что организация хакатона была на том уровне, которого я ещё не видел, и менторы очень сильно нам помогли, весь период хакатона готовы были с нами общаться, за что им отдельная благодарность, Роман Николенко, backend-разработчик.

Все презентации команд можно посмотреть и оценить здесь, а вот тут есть еще и церемония награждения.

Общий призовой фонд составлял 500 000 рублей. В каждом треке за первое место был выплачен денежный приз в размере 150 000 рублей на команду, а также подарен расширенный пак фирменного мерча нашего банка. За второе место выплачивалось по 100 000 рублей. За третье место каждый участник получил airpods и мерч. Все остальные команды получили мерч и нашу безграничную благодарность за участие, а создателю петиции на change.org мы презентовали фирменные тапочки, которым он был очень рад :)



Увидимся на следующем RAIFHACK!

Встретились онлайн 20 августа и рассказали подробнее о наших digital-решениях: девять команд Райффайзенбанка показали последние фичи и обновления от MVP голосового бота до подачи заявки на факторинг в семь кликов. Было много вопросов, делимся ответами и передаем впечатления с видео в статье!

Эффект присутствия

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

> 9 команд, которые показывают demo решений онлайн (никаких презентаций!)

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

> возможность задавать вопросы

> интерактив: от спикеров вам прилетает опрос, и нужно угадать, какую долю вопросов уже закрывает бот в текстовом канале, или сколько клиентов воспользовались функцией формирования декларации?

Запускаем трансляцию

00:10:48 >>> команда Chat

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

00:30:23 >>> команда Leasing

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

00:51:15 >>> команда RBO lite

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

01:08:29 >>> SME Digital

Проработали простой и понятный интерфейс для заказа справок и выписок онлайн. Сервис организован по принципу интернет-корзины. Вместе сравним функционал до/после и оценим преображение.

01:29:45 >>> R-Online

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

01:50:55 >>> Digital Lending PI

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

02:10:45 >>> SME Transactional

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

02:28:08 >>> Factoring

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

02:50:25 >>> SME Finance

Показываем формирование декларации, выпуск квалифицированной подписи и отправку документа в ФНС. Всё это быстро и легко через мобильное приложение на Android. Эта функция доступна не только в интернет-банке, но и в мобильном приложении.

Спасибо, что присоединились к нам

Были рады видеть вас среди зрителей Open Demo Day #2 в Райффайзенбанке! У нас получился крутой обмен опытом.

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

>>> Хотим встречаться ещё чаще: на нашем аккаунте в Timepad всегда ждем вас на открытые мероприятия.