Системный сдвиг

Сделал шпаргалку по структуре HTTP-запроса: Что где может находиться и что куда помещать при проектировании API? Куда положить версию API? Как сконструировать путь? Какие предусмотреть параметры запроса? Для чего использовать заголовки? Вопросы спорные, потому что в разных API и стайл-гайдах их решают очень по-разному, и единства мнений нет (а есть, наоборот, священные войны за то, как правильно и что соответствует RESTу!) В любом случае — все эти вопросы должны быть поставлены, по ним приняты решения и всё это внесено в документацию к API!

Стоит ли оно того? Прекрасную картинку нашел и перевел для вас! https://xkcd.com/1205/ Каждому автоматизатору процессов нужно повесить над столом — сколько времени вы можете потратить на оптимизацию/автоматизацию задачи, чтобы это оправдало себя хотя бы за пять лет? Если вы выполняете задачу раз в неделю, а ускорить её сможете на 6 часов — то целых 2 месяца! А если раз в месяц, а ускорить получится только на час — не больше двух дней. Что выбирать для автоматизации? Задачи, лежащие слева внизу: частые и которые получится ускорить на минуты и часы. UPD.: В реальности, правда, скорее выйдет так: https://xkcd.ru/1319/

Кем мы станем когда вырастем? С Юрием Куприяновым Долгожданный гость в нашей рубрике Юра Куприянов - автор канала Системный сдвиг, лучших докладов на Analyst days, ЛАФ, Flow. С Юрой поговорим о профессии системного аналитика: его прошлом, настоящем и будущем. 📒 Какие навыки и знания нужны, чтобы быть системным аналитиком? 💸 Зачем компаниям нужны системные аналитики? И что это за компании? 💻 Реально ли системному аналитику стать разработчиком, архитектором? И что для этого нужно? Наконец, мы узнаем, а кем станет сам Юра, когда вырастет? 📅Когда: 6 февраля в 18:30 🔗Где: онлайн, ссылка на регистрацию

Заманили меня поговорить про карьеру, в четверг вечером, если интересно — присоединяйтесь к трансляции! Ну а если не хотите ждать — можно прямо тут о чём-нибудь спросить, в комментариях к этому посту.

Почему-то вспомнил сегодня задачку от Сергея Нужненко: описать входы и выходы стиральной машины. Такая типовая задачка для аналитика/проектировщика систем. Подвох в том, что многие забывают то водоотведение, то электричество. Ну, опытный аналитик это всё учтет, конечно. А вот что вообще все забывают, и что является предметом специального обучения — это различные эксплуатационные факторы и воздействия. Например: ⚖️ машина имеет вес и центр тяжести, она давит на то, на чем стоит. При этом вес и центр тяжести разные в разных режимах. У машины есть допустимые углы наклона, при которых она сохраняет работоспособность и остается безопасной; 📳 машина подвержена вибрации и сама производит её, причем это тоже зависит от входа (вида и объема загрузки) — у всех, наверное, машина прыгала или даже падала, если узкая; у неё в целом есть резонансная частота и у отдельных её деталей есть свои частоты (например, у стекол и печатных плат — при входе в резонанс они могут треснуть); для крупных деталей с большой массой эти частоты не очень-то велики — поэтому у всех машин есть специальный режим для транспортировки; 🧲 машина подвержена электромагнитным излучениям и сама создаёт их; 🔨 машина подвержена внешним механическим воздействиям и имеет некоторую прочность; 💧 машина подвержена воздействию пыли и влажности; влажность она также может создавать сама; ♨️ машина подвержена воздействию тепла и создает его (это один из выходов); 🕶 машина подвержена воздействию ультрафиолета; 🪛 машина, возможно, имеет интерфейс для встраивания под столешницу (возможность работы без верхней крышки); Всё вышеперечисленное изучается в институте в рамках дисциплины "Конструирование". Ещё там всякие штуки про технологию производства, сборки, осуществления диагностики и ремонта, транспортировки, установки, обслуживания и настройки. Наш преподаватель про неё говорил так: у вас нет предмета "сопромат", который "сдал сопромат — можешь жениться", но есть конструирование. Я вам гарантирую, что это не хуже. Так оно и было, потому что все эти показатели нужно рассчитать, и сделать устройство так, чтобы в нём и паразитных ёмкостей не было, и оно не перегревалось, и центр тяжести не был смещён, и собственная частота не попадала в резонанс с типовыми частотами бытового или производственного использования (хуже всех было тем, кому попались бортовые приборы), да ещё и собрать его всё-таки как-то можно было бы при имеющихся технологиях. Примерно тогда у меня произошел один из моментов сатори — внезапного просветления — когда препод спросил на защите "А как выбор корпуса обусловлен планируемым годовым объемом выпуска устройства?" — тут-то я и понял, что всё со всем связано. Это потом сильно помогало в системном анализе. Возвращаясь к стиральной машине — я не знаю, какие для всех этих характеристик привести аналогии в программных системах и кто должен за них отвечать, но, кажется, как предмет это было бы очень полезно (предмет "конструирование ПО", к сожалению, вообще совершенно не о том).

Команда ЛАФ, оказывается, выложила запись моего доклада про историю и использование UML: https://rutube.ru/video/17ecbc3498379f11ab1c1ddacd8b6762/ С одной стороны, там результаты исследования современного применения UML (теперь мы документально знаем, что Sequence Diagram на первом месте, но и кроме неё кое-что применяется). С другой — интересно порассуждать, как менялись методы и нотации, и само представление о проектировании систем, пока менялись методы и технологии их создания. Сейчас, уже больше чем через полгода после этого доклада, можно ещё раз вернуться к теме, и посмотреть — какие тренды и что меняется, и как это можно визуализировать. Кажется, общие тенденции такие: — тренд на грануляцию и изоляцию: сначала выделение подпрограмм, потом — классов, теперь — микросервисов и даже отдельных функций в виде сервисов. Соответственно, с увеличением числа элементов они перестают помещаться на любой диаграмме в видимом формате. Получится что-то вроде карты звездного неба с созвездиями. — накопление готовых наработок: библиотек, фреймворков и сервисов. Само программирование превращается зачастую просто в клей, который соединяет готовые компоненты. Нужно ли это визуализировать, есть ли в этом вообще ценность? — укрупнение систем. Системы стали гигантскими, сотни и тысячи микросервисов — не редкость. Естественно, это тоже ни на одну диаграмму не влезет. — массовое внедрение конвейерных систем обработки — типа очередей, пайплайнов. Исторически визуализации это не очень хорошо поддерживают, та же Sequence Diagram скорее про точечные обращения друг к другу. С точки зрения инструментов визуализации (и проектирования через визуализацию) — обещанные в фантастических фильмах и книгах 3D-модели как-то не прижились. Хотя вот Fanсade выглядит интересно, детям после Майнкрафта хорошо заходит, лучше чем Scratch. В общем, пока у меня не складывается картинка, что может прийти на смену UML (или C4) в качестве "чертежей" для программных систем, и нужно ли это. Но, по ощущениям, что-то зреет — между SADT и UML прошло примерно 25-30 лет, от создания UML — 30, пора чему-то новому появиться.

Вдогонку к посту про неопределенность. Кажется, я понял. Это же не неопределенность. Это неизвестность! Это не неуверенность, не неоднозначность, не нечеткость. Это просто неизвестность. Аналитик уменьшает неизвестность. Когда неизвестно, что делать. И это сразу нас приводит к фреймворку Cynefin, помните — про какую проблему идёт речь — понятную, сложную, комплексную или хаотичную. Там в середине как раз "неопределенная". Вот аналитик и помогает эту "неопределенность" сдвинуть куда-то в понятную область, потому что там есть стратегия решений для разных видов проблем. Для понятной проблемы — выяви-классифицируй-реагируй — это бизнес-процесс. Для сложной — оцени-проанализируй-реагируй — это анализ. Для комплексной — исследуй-воспринимай-реагируй — это исследование. Для хаотической — действуй-чувствуй-реагируй — это интуиция. Так вот Cynefin Framework — он весь про знания, и сначала "понятные" и "сложные" назывались "известными" и "познаваемыми". Мне всегда хочется чего-то более сложного, чем матрица 2х2, и вот [специально для таких, как я] Сноуден год назад опубликовал расширенную версию, "матрицу неопределенности", чисто про знания. Теперь всё понятно — тут две шкалы: эпистемологическая, то есть — что нам известно про проблему, и онтологическая, то есть — какова сама проблема по сути. Понятная — проблема известная, и нам про неё всё известно. Сложная — проблема в принципе познаваема, и нам про неё известно, т.е., мы знаем, чего мы не знаем. Комплексная — проблема вообще известна, но неизвестна лично нам. Парадоксальная — проблема познаваема, но нам неизвестна — не знаем, чего не знаем (но можем узнать). Комплексно-хаотическая — мало того, что проблема нам неизвестна, она ещё и непознаваема. Лиминально-сложная (пугающая) — немыслимая для нас, но в принципе познаваемая. И, наконец, действительно хаотическая — немыслимая и непознаваемая. Вот это уже больше похоже на истинную картину. И, кроме действий для каждого домена, Сноуден дает ещё и фитнес-функцию для систем: в левом нижнем углу они должны стремиться к устойчивости в смысле робастности — то есть, сохранять свои свойства при незначительных изменениях внешней среды; в правом верхнем — к резильентности, то есть способности выживать при резких изменениях.

Аналитик нужен для снижения неопределенности. Или для борьбы с ней. Вынесу из комментов, это достойно отдельного поста. Часто при обсуждении смысла и ценности роли аналитика (особенно системного аналитика!) говорят про снижение неопределенности. Это такой типовой ответ. Хуже того — даже в профстандарте это есть! Аж в четырех местах: "...определять задачи на доработки, устранение противоречий и неопределенности" "...определять [..] уровень оставшейся неопределенности [после сбора данных]" и "собирать данные о неопределенности (нехватке информации, источников данных, проектных решений)" (не перепутайте!) "Анализ последствий выявленной неопределенности" Вот только это слово "неопределенность" само по себе содержит неопределенность. Какую именно неопределенность мы имеем в виду? Я люблю переводить всякие слова с одного языка на другой. Например, на английский — он интересен тем, что "сделан" примерно из 3-4 разных языков, и в нём, скорее всего, одно слово на русском превращается в несколько с чуть разными значениями. Помню, на экзамене нужно было перевести статью с названием "Precision And Accuracy", чуть не засыпался сразу на названии; и так со многими словами — efficiency, efficacy и effectiveness, например. Так вот, неопределенность по-английски бывает: 🤷🏼‍♂️uncertainty — это "неуверенность", нехватка информации — либо о том, что есть; либо о том, что будет (к чему приведет то или иное решение). Скорее всего речь идёт об определенных состояниях, но мы не знаем, какое выбрать. Если пытаться это измерять, то получится перечень возможных состояний, их вероятности и график распределения плотности вероятности (например, как в этом посте — мы не уверены в дате окончания работ, но можем её оценивать). Эта неопределенность связана с понятием риска. И с понятием выбора. То есть, не то что мы не знаем, что вообще может быть — мы, скорее всего, знаем, какие есть варианты, но не можем выбрать один из них. 🤌ambiguity — это "неоднозначность", "двусмысленность" — это как раз про неопределенность результата. Не то, что мы выбрать один из вариантов не можем — мы вообще не понимаем, чем эти варианты отличаются. Или не понимаем, чем отличаются исходные параметры. Или разные участники понимают их по-разному. 😶‍🌫️vagueness — это "нечеткость", слышали про нечеткую логику? Это про граничные кейсы и разделение двух концептов или статусов. Когда мы четко не можем отделить одно от другого. Что значит, например, "человек посетил доклад"? Слушал от начала до конца? Начал слушать, но потом ушел? С середины ушел, или почти сразу? А если наоборот — зашел на середине и остался? Или ближе к концу пришел? Или заходил пару раз, постоял у дверей, и вышел? Ничего не понятно, а в аналитике его посчитать как-то нужно. Ещё бывает confusion — это уже совсем не неопределенность, это скорее путаница: когда вся информация у нас есть, но мы не понимаем, что с ней делать. С этим аналитик тоже часто сталкивается. Можно сказать, что я душню, но эти различия важны: к их решению нужно подходить по-разному. uncertainty мы решаем через многофакторный анализ, плотность распределения вероятности, вычисление доверительных интервалов и т.п. А ещё с этим связаны робастность, то есть устойчивость, и сложность (robustness, complexity). Устойчивость — это про разброс входных параметров — получим ли мы результат с той же точностью, если входные параметры или среда немного изменятся. но при этом желательно, чтобы сложность системы не росла. Это уже про архитектуру. ambiguity устраняем понятно как — через определение общего языка, прояснение концептов, а если не выходит — через изоляцию их в разных частях системы — привет DDD. К vagueness можно подходить через ту же нечеткую логику, ну и ещё всякие штуки с логикой и хитрыми моделями данных. В общем, говоря про неопределенность, желательно определиться — какой именно её вид вы имеете в виду.

Какие жанры докладов бывают? 1. 🥱"Унылые позавчерашние новости". Самый распространенный жанр. Жанр по умолчанию. Жанр, в который скатывается 90% всех инициатив "что-то рассказать нашему комьюнити от таких же, как мы". Именно из-за этого жанра большинство конференций, курсов и т.п. слушать невозможно. Почему так? Следите за руками: — Спикер такой же, как и те, кто сидит в зале 🤷‍♂️. А это значит, что ничего экстраординарного в его работе нет. Ну, в сравнении с такими же, как он, в зале. — Мы берем хороший случай — это толковый спец 👌. Онтак же хорошо, как и любой другой в зале понимает тему. Но он не радикально дальше рынка, в дали, про которые никто в зале не слышал и не пробовал. Просто потому, что все делают примерно одно и тоже. — 😨 И он боится облажаться. — 🕰️Поэтому рассказывает только о том, в чем он уверен. А это — позавчерашние новости. Не надо делать такие доклады. Дальше пойдут хорошие жанры докладов: 2. 🔬 Рассказ о про то, что спикер действительно знает лучше, чем аудитория. Это

Вау! Вас уже больше 8 тысяч, дорогие читатели, и это круто!🎆 Большое вам спасибо за доверие и интерес! 🤝 А вот вам по случаю круглого числа немного статистики. Мне давно уже было интересно — а сколько нас всего — в смысле, сколько системных аналитиков в РФ, ну или тех, кто так или иначе причисляет себя к ним? По оценкам, которые мы делали разными способами, получалось, что примерно 30-40 тысяч. И вот, наконец, я нашел источник, на который можно сослаться! НИУ ВШЭ публикует ежегодный статистический сборник "Индикаторы цифровой экономики", и там есть данные по занятости в ИТ, а среди них есть системные аналитики! Сейчас опубликованы данные за 2022 год, их и будем смотреть. Так, всего в ИКТ на 2022 год занято почти 1,9 млн. человек, из них разработчиков и аналитиков программного обеспечения и приложений — 761 тыс. (в 2021 было 800 тыс., между прочим). Такие дела, нас считают вместе с разработчиками. Так сколько же именно аналитиков? Из этих 761 тысячи — 4.6%, то есть 35 тысяч! Вот так, всего-то. То есть, если считать, что тут у меня только системные аналитики, то это было бы 22,8% всех системных аналитиков в РФ! Но тут, конечно, не только системные аналитики, я-то знаю :) Кстати, надо будет сделать опрос, очень интересно. Что ещё можно вытащить из этих данных? Ну, например, теперь мы знаем среднее соотношение: на одного аналитика приходится примерно 21,5 разработчиков. Ну, это лукавая цифра, конечно — скорее, это говорит о том, что во многих компаниях разработчики работают без аналитиков вообще. Экспертно мы всегда оцениваем примерно как 1/10. А вот, например, про дистанционную работу: 27.5% людей в ИТ работают дистанционно по состоянию на 2022 год. Теперь мы знаем точно, что не все и даже не половина. Генерирует вся эта шняга около 3% ВВП в год, или 4,2 трлн. руб. в абсолютных числах. Из них, правда, чисто софт — всего 1,9 трлн. Зато рост цен на разработку и приобретение ПО в 2022 году — 35%! (в предыдущие годы был 3 и 7). И средняя зарплата теперь 151 тыс. (сравните со своей, на всякий случай). Вот такая интересная статистика. Ещё интересные данные про пользователей, чтобы вы не очень на их навыки рассчитывали. Вот как вы думаете — какой процент людей в возрасте от 15 лет может отправить электронное письмо с вложением? А сколько процентов владеют искусством копирования и вставки в электронных документах? И какой процент людей может изменить настройки доступа к какой-нибудь информации? (в тексте почему-то "настройки доступа к учетной записи", я не понимаю, что они имеют в виду). Пишите в комменты! В общем, поздравляю себя с очередным круглым числом подписчиков, а вам желаю, чтобы вы по любой статистике были всегда в топе! (особенно в топе зарплат, желательно 📈)

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

В схеме из поста приведена двойная классификация: с одной стороны, по книге "Паттерны интеграций корпоративных приложений" (Enterprise Integration Patterns, EIP) Грегора Хопа и Бобби Вульфа, там перечислены такие стили интеграции ("известные на момент написания этой книги", т.е. на 2003 год): - Передача файла - Общая база данных - Удаленный вызов процедуры - Обмен сообщениями Собственно, авторы довольно быстро подводят к выводу, что стиль "обмен [асинхронными] сообщениями" самый лучший, и дальше всё разбирается в основном в отношении него. Хотя, конечно, многие паттерны довольно универсальны, т.к. представляют собой решения проблем, возникающих в любом проекте интеграций, безотносительно технологии, по которой он сделан. Основанием для классификации в данном случае выступает природаканала, через который производится обмен, куда пишется сообщение: в файл на диске; в базу данных; никуда не пишется, а пакуется в TCP-пакет и летит по сети; или в промежуточную очередь/шину (в широком смысле — MOM: Message Oriented Middleware). Это всё логические абстракции, обусловленные программной обвязкой: строго говоря, база данных — это тоже набор файлов, как и журналы Кафки, например. Да что там, сокет TCP для операционной системы тоже файл, никакой разницы. В основе своей всё — файловый обмен :)) Книга EIP немного касается содержания сообщений, выделяя такие: - Сообщение с командой - Сообщение с документом - Сообщение о событии - Запрос - Ответ (подтверждение, результат, исключение) При этом Хоп и Вульф не связывают типы сообщений и стили интеграции, хотя, конечно, есть определенное родство: напрмиер, передавать команды через файловый обмен можно, но это скорее редкость; а события чаще передают через асинхронный обмен сообщениями. Вторая классификация взята из книги Майка Амундсена и др. "Непрерывное развитие API" (Continuous API Management), написанной в 2018. В ней речь идёт не вообще об интеграции, а именно про API (сравните смещение ракурса за 15 лет!), и классификация стилей построена как раз на типах сообщений: что мы передаем и что ожидаем в ответ. В первой редакции отдельно про стили API не говорилось, они просто упоминались, как что-то известное. Во 2-й редакции — в 2021 году — появилась отдельная глава, там перечислены такие стили: - Туннельный (это RPC — выполнение команды на удаленном сервере) - Ресурсный (это "простой" REST, в первой редакции книги он называется "CRUD-over-HTTP") - Гипермедиа (это HATEOAS из REST'а: не просто содержание ресурса, а также и необходимые ссылки для работы с этим ресурсом, связанные с ним ресурсы и даже, возможно, какой-то воркфлоу/код для обработки) - Стильзапросов (это когда API предоставляет единую точку для выполнения произвольных запросов: GraphQL, SparQL, поисковые запросы через HTTP и т.п.) - Событийно-ориентированный стиль (это и паттерн "издатель/подписчик", и вообще любая реализация асинхронного обмена). Как можно видеть, обе классификации пересекаются, но не совсем. То, что у Хопа упомянуто вскользь (RPC), у Амундсена раскрыто в деталях (разные стили синхронного взаимодействия), и наоборот (асинхронный обмен сообщениями). Хуже того — мало кто знает, но у Хопа есть вторая книга: Enterprise Integration Patterns, Vol. 2: Conversation Patterns, вышедшая в 2019, не переведенная на русский, и содержащая как раз в качестве одного из паттернов тот же HATEOAS, например (в первой книге никаких упоминаний REST вообще нет, там сплошной SOAP). Идея второй книги примерно в русле Амундсена — да и написаны они, видимо, примерно в одно время: кроме технических моментов, связанных с синхронностью/асинхронностью, гарантией доставки, преобразования данных, маршрутизации и т.п. в интеграционных взаимодействиях ещё имеет значение их последовательность, "разговор", "conversation". У Хопа в второй части EIP появляются паттерны, обеспечивающие как раз этот разговор: оркестрация, хореография, гипермедиа, и новые паттерны, характеризующие стиль общения (например, поллинг и ретраи). В эту же сторону движется и OpenAPI Initiative со своим новым стандартом Arazzo Specification.