• наше собственное приложение Mir Pay;
• приложение, разрабатываемое одним из наших партнеров по нашим спецификациям.

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

Эту проблему отчасти удалось решить при помощи спецификации OpenAPI (OAS 3.0)^[1], но все равно часто встает вопрос о правильном применении и подводных камнях кодогенерации, например на языке Java. И можно ли полностью предоставить аналитикам написание функциональных требований, документации и моделей в yml форме для OpenAPI, а разработчикам предоставить возможность только написание бизнес-логики?

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

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

Предисловие

Хочу поделиться опытом создания системы автоматизации функционального тестирования на языке на Kotlin.
Основой для создания / конфигурирования / запуска / контроля выполнения тестов — будет набирающий популярность молодой фреймворк Kotest (в прошлом Kotlin Test).
Проанализировав все популярные варианты для Kotlin — выяснилось, что есть всего два "нативных":

• Spek
• Kotest

Либо бесконечное кол-во из Java мира: Junit4/5, TestNG, Cucumber JVM или другие BDD фреймворки.
Выбора пал на Kotest с бОльшим кол-вом "лайков" на GitHub, чем у Spek.

Руководств по автоматизации тестирования на Kotlin, особенно в сочетании с Kotest — немного.
Думаю, что написать цикл статей про Kotest, а также про организацию проекта авто-тестов, сборку, запуск и сопутствующие технологии — хорошая идея.

Все части руководства:

• Часть 2. Kotest. Deep Diving
• Часть 3. Расширения и Spring Test

Привет! Меня зовут Игорь Николаев, я пью за любовь работаю в отделе автоматизации процессов разработки Мир Plat.Form в НСПК. В этой статье я поделюсь тем, как наш отдел решал задачу по автоматизации предоставления различных ресурсов для команд разработки. Эта задача свойственна организациям с большим количеством проектов, инфраструктура которых состоит из распределенных и, возможно, слабо связанных сетевых сегментов.

В статье описан PoC (Proof of concept) решения задачи выделения ресурсов в рамках сервисов CI/CD (Continuous Integration & Continuous Delivery) и предоставления привилегий для пользователей этих сервисов.

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

ansible devops codestyle

Hey! Меня зовут Денис Калюжный я работаю инженером в отделе автоматизации процессов разработки. Каждый день новые сборки приложений раскатываются на сотнях серверов кампании. И в этой статье я делюсь опытом использования Ansible для этих целей.

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

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

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

Привет, Хабр! Меня зовут Алексей Назаров. Я занимаюсь автоматизацией в отделе администрирования инфраструктурных систем в Национальной системе платежных карт (АО НСПК) и хотел рассказать немного о наших внутренних продуктах, которые помогают нам развиваться.

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

С появлением на рынке микропроцессорных платежных карт наряду с хорошо и давно знакомым к этому времени методом для верификации держателя карты PIN Online, когда значение ПИН проверяется эмитентом карты на его хосте, начал повсеместно применяться метод PIN Offline.

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

Несмотря на то, что оба метода верификации параллельно используются вот уже 15 лет, до сих пор иногда приходится слышать вопросы: какой метод обеспечивает более высокую безопасность при обработке операции- PIN Online или PIN Offline? И вообще- можно ли эмитенту (банку, выпустившему карту) обойтись только одним из указанных методов проверки ПИН? Например, методом PIN Online. Очевидно, с точки зрения эмитента этот метод проще метода PIN Offline при реализации процедур персонализации карты, изменения ПИН держателем карты, контроля лимита на число попыток ввода неверных значений ПИН, поскольку в этом случае перечисленные процедуры выполняются только на хосте эмитента и не требуют применения дополнительных действий на стороне платежного приложения карты.

Привет, Хабр! Меня зовут Игорь Тулинов. Я руковожу центром архитектуры ИТ в Национальной системе платежных карт (АО НСПК) и хочу рассказать о том, как наша компания пришла к решению внедрить процессы управления Enterprise-архитектурой, выделить штат архитекторов предприятия и реализовать архитектурный контроль на ключевых стадиях создания ИТ-ценности.

В ИТ отрасли термин «Архитектура предприятия» (Enterprise Architecture) появился более тридцати лет назад. Со временем возник широкий ряд определений этого понятия, моделей, фреймворков и стандартов его описания. Во множестве ИТ и финтех компаний в том или ином виде реализованы процессы управления корпоративной архитектурой.

Но в какой именно момент в компании появляется Архитектура предприятия? Когда и на основе чего организация приходит к пониманию, что настало время внедрять процессы управления корпоративной архитектурой?

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