Вместо того, чтобы представить Для кого я решил написать? Эта статья была написана для моих коллег-аналитиков или для тех, кто хотел бы ими стать.
Если вы сейчас хотите стать аналитиком, то подумайте хорошенько.
Микросервисы.
При ажиотаже вокруг них лучше быть разработчиком, архитектором, тестировщиком, руководителем проекта, дизайнером.
В микросервисах хорошо быть кем угодно, но не аналитиком.
Аналитик всегда и во всем виноват. Я никогда не слышал, чтобы архитектора или даже девелоперского проекта обвиняли в «обмане» и нарушении сроков.
Нет, господа, вина всегда лежала и всегда будет лежать на плохой документации и нечетко поставленных задачах.
Вся команда собралась и показывает на тебя пальцем.
Говорят, это все он! Опытный архитектор спроектировал, хороший разработчик сделал, внимательный тестировщик протестировал, мотивированный менеджер проекта предоставил.
а невнимательный аналитик все провалил.
Между тем, материалов по аналитике и тому, как ее проводить, на русском языке очень мало.
А как «анализировать» эти самые микросервисы — не совсем понятно.
Более того, никто вам не расскажет, чем теперь отличается «системный аналитик» от «архитектора решений».
Это то, что мне хотелось выяснить и поделиться.
Поэтому, если вы не аналитик, не читайте.
Вам не будет интересно.
Ведь у вас нет экзистенциального кризиса или вопросов «Кто яЭ» и зачем я им нужен на проекте».
Самая популярная задача для аналитика — разрезание «монолита» на «микросервисы».
Зачем нужен был аналитик? Пишите документацию! Дело в том, что за последние 2 года в Enterprise наметилась четкая тенденция — разрезание «монолита» на «микросервисы».
Часто причиной этого процесса является угроза санкций; Есть мнение, что «монолит» сопровождает вендор, лоббирующий интересы западных разработчиков ПО.
Хотя я бы выделил главную причину так называемых «гибких методологий» или, как мы часто говорим, вольно и вообще — Agile. Мы пробовали поддерживать «монолит» в двухнедельных спринтах и поняли, что это проблематично — постоянно меняющиеся API, модели данных и интерфейсы влияют на всю систему и на ее поддержание тратится слишком много ресурсов и нервов.
Стало ясно, что необходим какой-то новый подход. Итак, мы обратились к архитектурному стилю, описанному Мартином Фаулером 10 лет назад, — микросервисам.
Действительно, очевидным преимуществом микросервиса является то, что его может легко обслуживать один человек.
И конечно, казалось бы, такую систему, на первый взгляд, будет легче масштабировать как по горизонтали, так и по вертикали.
Поначалу идеи были революционными:
- Мы убиваем традиционный ESB и заменяем его несерьезным решением вроде Kafka, обеспечивающим асинхронное взаимодействие.
Там, где асинхронное взаимодействие не требуется, мы используем REST API.
- Мы убиваем централизованное хранилище на базе СУБД Oracle и заменяем его бесплатным на базе PosgtreSQL. Более того, все говорили, что у каждого микросервиса есть своя отдельная база данных.
- Стандартов больше нет. Каждый имеет право использовать свою модель данных и свой стек технологий.
Возник вопрос, как вести документацию в условиях этого процесса? Собственно, этот вопрос и стал причиной того, что позже эйфория утихла и стали очевидны некоторые неоспоримые факты и недостатки микросервисного подхода.
- Содержать большую микросервисную систему целиком оказалось сложно.
Если вы помните Agile-манифест, в нем есть такой момент, что «работающий продукт важнее документации».
Часто это приводило к отсутствию документации вообще.
Да даже если и было, то из-за написания разными командами была сильная разница в терминологии.
В своих предыдущих работах и выступлениях я называл это явление «смысловым безумием».
В случае «факапа» такая «сумасшедшая» документация требовала дополнительной оценки и сравнения, что требовало дополнительного времени.
Причём, если в «монолите», сопровождаемом одним вендором и одной, пусть и большой, командой, паттерны проектирования были одинаковыми и сопоставимыми, то в микросервисах каждая команда выбирает свой API и свой стек технологий.
- Внезапно вспомнили о так называемых нефункциональных требованиях.
Оказалось, что время обработки и производительность микросервисных систем не так уж высоки.
Почему так случилось? Гибкая и плохая коммуникация в команде в условиях слабого архитектурного контроля порождают большое количество точек интеграции.
А так их как-то нужно синхронизировать по таймингу с одной стороны, а с другой стороны, помните, что подключение к адаптеру (он также может быть «фасадом» или «маппером») и отключение от адаптера происходит за конечное время.
время.
Кроме того, стоит сказать, что финтех подразумевает лавинообразный рост пользовательских подключений (например, мы видели это в начале пандемии, когда резко увеличилось количество покупателей в интернет-магазинах) и чтобы ему противостоять, аварийные и резервные механизмы должны быть продуманы заранее.
И кто должен был предложить эти решения? Архитектор? Нет, коллеги.
Они стали ожидать от аналитиков решений на уровне команды.
Изменилась сама структура ролей.
Здесь можно выделить следующие тенденции.
- В результате бизнес-аналитики начали умирать, а люди с инженерным опытом или, как часто говорят, «бэкграундом», начали набирать вес, их еще называют «системными аналитиками».
Почему это происходит. Поскольку зрелость бизнеса возросла, а в среде Agile работа бизнес-аналитиков часто заключается в переписывании отзывов клиентов о спринте в диаграммы, которые плохо понятны команде.
Между тем, из-за отсутствия общего стандарта, единой модели данных и плохой коммуникации техническая часть стала требовать более тщательного анализа и предварительной разработки.
- Роли и функциональные обязанности архитектора, тестировщика и аналитика объединились.
Почему это происходит. Ну, во-первых, Agile. В его рамках только разработчики не берут на себя чужую ответственность.
Остальные делят их между собой.
Во-вторых, из-за небольшого временного периода люди имеют разный опыт работы с тем или иным стеком.
Хотя, хотелось бы отметить один интересный факт. Несмотря на смешение ролей, в случае каких-то неудач в ходе проекта виноватым оставался только аналитик.
Архитектор и испытатель развели руками и сказали, что они тут ни при чем.
В клинике есть хирурги, есть лаборатория, есть анастазиолог и психиатр, есть терапевт. Он везде знает немного и пишет историю болезни.
В случае чего он может поставить диагноз и знает специалиста, который «точно сможет» это вылечить.
ГОСТ 19, ГОСТ 34, ITIL и COBIT все?
К сожалению, да.Хотя, наверное, стоит сказать, что все практики, использовавшиеся ранее в Agile, требовали переосмысления, а не отмены вообще.
Почему так случилось? Неужели в старых методах не было ничего хорошего? Почему мы пришли к гибким методологиям? Agile используется, когда непонятно, что нам нужно делать, и мы предполагаем, что цели и задачи, а также ИТ-стратегия (в том смысле этого термина, который указан в COBIT) изменятся.
Это означает, что в гибких методологиях изменился и подход к написанию и ведению документации.
И к роли аналитика, следовательно, подход тоже должен измениться.
Каждый спринт рождает новые задачи и писать каждый раз документ, как того требует ГОСТ 19 — безумие.
В качестве примера успешного применения «гибкой методологии» привожу пример создания логотипа «Hello Kitty».
Уже через год дизайнер Юко Симицу смог нарисовать логотип магазина игрушек, который всем понравился.
Секрет успеха этого логотипа прост – каждый свой новый эскиз дизайнер показывал потенциальным покупателям этого магазина.
Спустя год работы результат его работы оказался идеальным.
В целом подходы Юко Симицу не новы для Японии.
Стоит вспомнить принципы бережливого производства, описанные в культовой книге «Дао Тойоты».
Да-да, эксперты SCRUM скажут, что Мартин Фаулер и компания взяли идею оттуда.
Но что это значит для нас? Прежде всего, мы не пишем документ раз и навсегда.
В каждом спринте у нас есть задача разработки, которую мы обновляем перед началом каждого спринта.
И здесь не может быть ни общего стандарта, ни правил хорошего тона.
Подобную документацию можно писать в JIRA, ASANA или модном сейчас продукте Atlassian Confluence. Хотя, если в одном из проектов, где всё было завязано на битбакет, мы использовали документацию, написанную в формате markdown и хранившуюся прямо в репозитории в ветке, соответствующей спринту.
Но в целом тенденция такая: документация с подробным описанием — Confluence. Карточка с указанием времени создания задачи, кто отвечает за выполнение, краткое описание и срок выполнения — Jira, а материалы для выполнения — git или bitbucket. Чтобы не запутаться в этом море разнообразных артефактов, необходимо их четко зашифровать, чтобы понять, к какой задаче относится артефакт. И очень удобно для такого шифрования использовать так называемый билет в Jira, как «головную сущность», к которой привязаны все остальные артефакты.
Билет тоже не существует сам по себе, а привязан к какому-то git-эпику и agile-спринту.
Более того, у «эпика» и «спринта» тоже есть свои коды.
Где следует указывать этот шифр: он должен появиться в заголовке страницы Confluence и в коммите Git или Bitbucket. Кстати, ветки git тоже нужно содержать в порядке.
Все изменения должны быть объединены в главную ветку из ветки, имя которой включает код задачи из билета Jira. Это единственный способ найти нужный артефакт с помощью поиска в веб-форме.
И многие поначалу очень буквально восприняли фразу о том, что документация не так важна, как работающий продукт. Спустя два года стал ясен истинный смысл этой фразы из Agile-манифеста.
Так, в начале пандемии из-за того, что количество карточных платежей увеличилось, один из ритейлеров просто отказался от карточных операций при неожиданно возросшей нагрузке.
Мы начали разбираться.
И документации нет. Те разработчики, которые это сделали, уже уволились.
Оставили кучу веток и непонятных коммитов в git. Правда, архитектор остался.
Но он в Пунта-Кане, пьет ром и выключает телефон.
Так что документация не так важна, если продукт работает и устойчив к «черным лебедям».
Из вышесказанного следует, что документация не только не становится необязательной, но и повышает ее значимость.
Меняется только система его производства.
Это становится Agile-артефактом.
И это должно быть вплетено в его систему.
Документация по-прежнему должна быть подготовлена аналитиком и должна охватывать следующие категории:
- Описание API, протоколов и контрактов.
То есть все маппинги, преобразования, модели данных.
Правилом хорошего тона является указание действительных примеров сообщений.
Особое внимание следует обратить на идемпотентность операций.
Если, например, вы реализуете логику через REST API, вам необходимо понимать разницу в HTTP-глаголах.
- Описание модели взаимодействующих систем.
Модель остается классической – звонок «поставщик-потребитель».
- Описание баз данных.
Таблицы, все ограничения и ключи должны быть описаны.
Особое внимание следует обратить на кратность.
Необходимо указать, с каким типом соединения вам необходимо работать: «один-к-одному», «один-ко-многим», «многие-ко-многим».
Эту документацию должны писать аналитики, предварительно согласовав их с архитекторами.
Никто не запрещает, и нет противоречия с Agile, если эти пункты написаны в рамках традиционных подходов, таких как Itil, COBIT или ГОСТ19. Несмотря на то, что такая документация верхнего уровня может быть написана и в MS Word, важно лишь правильно зашифровать версии документа, привязав шифры к процессам.
Но затем начинаются усовершенствования «гибких методологий».
Разумеется, в исходную документацию вносятся изменения.
В этом случае для каждого улучшения или «новой функции» создается новый.
Что такое «микросервис» технически и чем он принципиально отличается от «монолита»?
Хороший вопрос, не так ли? Вам часто задавали этот вопрос в интервью.Давайте попробуем разобраться.
Здесь следует начать с того, о чем говорил Мартин Фаулер в 2012 году о так называемой «слабой связи».
И «слабая связь» становится центральной концепцией микросервисной архитектуры.
Цитируя классика, это означает, что внесение изменений в один объект оказывает минимальное влияние на остальные объекты системы.
Как это реализовано? Микросервисы упакованы в так называемые «контейнеры», которые являются функциональными синонимами виртуальных машин.
Правда, в отличие от виртуальных машин, у них нет собственной операционной системы, есть только базовые команды UNIX. Контейнеры оркеструются через специальную платформу, которая распределяет нагрузку, координирует взаимодействие и масштабирует всю систему.
Как правило, под такой платформой понимают всем известную систему Kubernetes. Зачем я все это рассказываю? Ведь документацию пишут аналитики и внутренняя начинка им вроде бы не нужна.
Дело в том, что при микросервисном подходе, как и в «кастоме» (от английского слова «custom» — «покупатель».
В данном контексте разработка самостоятельно без вендора) фантастически важно не только учитывать учитывать нефункциональные требования, но и уметь их описывать.
И если раньше они были прописаны в документации верхнего уровня, то с появлением «гибких методологий» их важно не забывать, учитывать и регистрировать.
Это требования относительно:
- Нагрузки.
Аналитику важно понимать, какую нагрузку выдержит инфраструктура.
Есть такая метрика как rps (запросов в секунду).
Это нужно уметь оценить и просчитать.
И помните, что DDoS-атаки — не миф.
Особенно в финтехе.
- Время обработки.
У каждого бизнеса есть свои требования.
Например, в одном из проектов, в котором я участвовал, время обработки розничной заявки было ограничено 45 секундами.
Таким образом, аналитик теперь должен понимать, какие процессы требуют времени.
Временные диаграммы («диаграммы Ганта» и «последовательность») могут стать хорошим украшением вашей документации.
- Количество одновременно подключенных пользователей.
По сути, это та же нагрузка, но подключение пользователя влияет на такие аспекты, как «авторизация» и «аутентификация».
А если эти два процесса вынести в отдельный микросервис, то следует учитывать нагрузку на него.
- Безопасность данных.
Этот момент становится все более важным.
С одной стороны, это касается персональных данных и конфиденциальной информации, а с другой – возможности совершения транзакции.
Аналитику важно понимать, где выполняются эти операции и где накапливаются эти данные.
Если раньше аналитики не должны были чувствовать разницу между передом и задом, то теперь они обязаны ее чувствовать.
Я бы сказал, что аналитикам было бы полезно начать понимать, что предоставляют экосистема языка Javascript (спереди) и экосистема языка Java (сзади).
За что? Например, прекратите отправку данных на передний план.
- Возможные ошибки.
Хорошая новость в том, что необходимо создать так называемую «фабрику ошибок», которая бы интерпретировала сообщения о технических ошибках в текст, понятный пользователю.
Это нужно даже не для абстрактного отражения в документации, а для планирования тестирования.
Ведь тестировщик рано или поздно появится и расскажет о стратегии тестирования.
Еще один важный момент — проектирование механизмов дублирования, обработки невалидных сообщений, неудачных запросов и прочей нефункциональной дребедени.
И отныне все это управление должно стать неотъемлемой частью документации.
Переход от бизнес-аналитики к системной аналитике
За последний год грань между системным аналитиком и архитектором решений стала практически неразличимой.От аналитиков все чаще требуется «предлагать решения» проблем, которые ставит бизнес.
Это означает, что Agile и его подходы поставили под сомнение необходимость методов бизнес-анализа.
Лет 5 назад было абсолютно нормально говорить бизнесу, что ему нужно.
Это уже не так.
Бизнес теперь диктует ИТ, что ему нужно, и сам предоставляет аналитику.
В проекте продуктовая команда должна принять бизнес-требования и правильно оценить ресурсы, необходимые для реализации.
И тут от аналитиков начинают требовать знаний, которые раньше мало требовались.
Жил-был святой Августин, который говорил об «однозначности».
То есть суть вещей для Бога и для человека должна быть одна и та же.
Всем давно пора понять, что бизнес для нас – это Бог.
Он творец, он творец, и не надо ему говорить, что ему нужно.
Итак, бизнес дал «обратную связь по характеристике» и задачей анализа становится реализация плана.
Поэтому в последнее время бизнес-логику приходится строить все реже, но акцент на нефункциональных требованиях в контексте микросервисного архитектурного стиля стал значимым.
Ниже я попытался классифицировать решения, которые необходимо предложить для решения бизнес-задач.
Ничего нового здесь нет, те же две «вечные темы» — интеграция, маршрутизация и базы данных.
- Интеграция.
Микросервисная архитектура как явление предполагает определенный плюрализм в сфере интеграционных решений.
Лично я выделяю четыре метода интеграции:
- Через очередь (и сюда входит и транспорт на базе Kafka, который, строго говоря, очередью не является)
- Через HTTP-вызов.
Это может быть REST API или старомодный способ SOAP.
- Через базу данных, почему бы и нет?
- Через файл Да-да.
Государственные учреждения часто используют протокол обмена файлами.
А иногда это действительно безопаснее.
-
Asp Или Php?
19 Oct, 24 -
Хакеры: Россия И Китай
19 Oct, 24 -
10 Главных Качеств Лидера По Версии Google
19 Oct, 24 -
Массовая Проблема: Физика Или Философия?
19 Oct, 24 -
Модульное Приложение На Asp.net 5
19 Oct, 24
