Записки системного архитектора

описание

Мысли, идеи и события из жизни системного архитектора и его коллег

← к каналу @sysarchthoughts

272

подписчиков

Охват к подписчикам

96,0%

ERR

Реакции к просмотрам

1,14%

91 на 29 постов

Пересылки к просмотрам

1,03%

Постов в день

0,0

всего 29

Где отзываются чаще

доля реакций к просмотрам

23 мая 2025 г.Всем привет. Давно не писал, а сегодня вдруг созрел #наброс на вентилятор. Периодически (да что там периодически - часто!) сталкиваюсь в ИТ среде с майндсетом, что нужно делать либо "хорошо", либо никак. Специально пишу слово "хорошо" в кавычках, чтобы подчеркнуть, что чаще всего это однобокая оценка, которая оценивает только одну-две характеристики решения, например, соответствие красивым схемам в книжках и статьях или эмоциональному чувству прекрасного говорящего.... С точки зрения же заказчика (того самого мистического "бизнеса", которого принято упоминать шёпотом при закрытых сборищах ИТ-шников) эти оценки чаще всего непонятны и выглядят попыткой запутать. Много раз говорил и повторю еще раз. Бизнес-закзачику нафиг не сдались все наши ИТ-шные заморочки. Все это - вынужденное зло, с которым приходится мириться. Заказчику нужно решение какой-то проблемы тем или иным способом. Мы будем нужны и востребованы ровно до тех пор, пока мы можем генерировать решение этой проблемы лучше, чем кто-то (или что-то - привет ИИ). Что значит лучше? Чаще всего это означает быстрее, дешевле, качественнее. Кстати, еще прикол в том, что если пытаться делать в лоб то, что просят - то чаще всего получится полная хрень (еще один привет ИИ 😊). Но это не потому что заказчик глуп и ничего не понимает. Это от того, что глупо делать то, что просят. Тут как пример вспоминается сюжет из записок врача Булгакова, когда к нему пришел пациент больной сифилисом с жалобой на горло и просил порошки для полоскания. Делать надо то, что нужно. И важнейший в нашей отрасли навык - это умение выслушать, что просят, понять (иногда не с первой попытки) что нужно, и придумать/предложить как это сделать так, чтобы и заказчика устроило с точки зрения сроков/качества, ну и самим было хотя бы не очень противно. Увы, часто бывает, что отличное решение с точки зрения заказчика может оказаться не очень красивым и удобным с точки зрения ИТ-специалиста, приходится искать компромисс. Еще и убеждать заказчика приходится, что это именно то, что ему нужно - это, кстати, отдельный навык 😉 Но что поделаешь - клиент платит...3,49%
2 апр.Пригласили меня тут в жюри школьного проектного конкурса, и вот что хочу сказать: мало кто может сформулировать проблему. А точнее — отличить проблему от факта. В основном авторы проекта в качестве проблемы формулируют некий факт. "Школьники стали реже заниматься спортом". "Мало кто знает историю своего района". "В школе часто меняется расписание". Это не проблемы, это факты. Их можно проверить. С ними ничего не происходит, это просто замеры, констатация. Возможно, это симптом или причина проблемы. Если вас это почему-то беспокоит, можно покопать и докопаться до проблемы, к которой эти факты приводят. К каждому такому факту можно задать вопрос "ну и что?", это будет шагом к определению проблемы. Мы не можем "решить" факт. Можем как-то изменить реальность, чтобы изменились факты (произошел импакт). Но чтобы понять, в какую сторону менять — нужно сформулировать проблему. Для школьников это нормально, они ещё учатся. Но то же самое происходит и в рабочей практике! И у аналитиков, когда они берутся за разбор какой-то темы или запроса от пользователей. "Медленно работает запрос". "У пользователей нет возможности скачивать документ с предыдущими изменениями". Тут мы видим ещё один частый антипаттерн: формулировка через отсутствие. "Не внедрена CRM". "Отсутствует возможность сделать ...", "У школьников нет понимания ...", "Задачи по математике не привязаны к реальной жизни" и т.д. Это тоже факт. Ну да, чего-то нет. Почему это проблема? А оно вообще нужно? А почему? А кому? А зачем? Следующая частая ошибка — формулировка не проблемы, а задачи. "Требуется реализовать возможность проверки действительности паспорта". "Сделать импорт ФИО студентов из файла". Если вы думаете, что такую фразу сложно представить, как проблему, то нет: "Проблема: оказание помощи отстающим ученикам". "Проблема: уменьшение числа заявок, введенных с ошибками". Ну в чем проблема — возьмите, да окажите. И делайте меньше ошибок. Проблема отличается от задачи как раз отсутствием понятного решения. Мы видим некоторый разрыв, но что с ним делать — непонятно. Если перед нами задача — нам не нужен аналитик. Собственно, аналитик нужен, чтобы превратить проблему в набор задач. (А продакт — чтобы понять, какие проблемы стоит решать) Что должно быть в формулировке проблемы? Там должен быть разрыв. "Наблюдается [X], а должно быть [Y], поэтому происходит [Z]" X — это как раз наш факт. Ему обычно не хватает Y — а как должно быть? И Z — что плохого из-за этого случается? "Школьники стали реже заниматься подвижными играми на переменах [тут должны быть данные, как раньше, и как сейчас], поэтому на последних уроках им тяжелее концентрироваться" Тут должно быть обоснование этой связки "подвижные игры — концентрация", потому что дело может быть в чем-о другом, например, в перенасыщенности CO2 в классах. Причины потери концентрации требуют отдельного исследования, которое в реальной жизни мало кто делает. Ну вспомните, давно ли вы рисовали причинно-следственную диаграмму? Да ещё с опорой на данные, а не потому, что так всем кажется? Следующий вопрос — чья это проблема? Кто страдает? Школьники, учителя, родители? Администрация школы, которой дадут по шапке за низкие результаты? Итого, получается несколько проверок на формулировку проблемы: 1. В формулировке есть разрыв (можно сформулировать конструкцию XYZ,описанную выше) 2. Есть "владелец боли". Ясно, кто страдает, и понятен негативный эффект. 3. От боли нельзя отмахнуться. Понятно, что если ничего не сделать сейчас — ситуация будет ухудшаться, возникнут риски. 4. Формулировка не содержит упоминания конкретного способа решения. При прочтении непонятно, что делать. 5. В формулировке нет субъективных оценок (медленно, неудобно, сложно, непонятно, плохо). 6. Формулировка не содержит отрицания, не упоминает отсутствие чего-либо. 7. Сформулирована ровно одна проблема (нет и/или/запятых). Зачем вообще выявлять и формулировать проблему? Почему не сразу брать в работу? Чтобы деятельность была осмысленной; чтобы решать проблемы, а не пилить задачи. Чтобы обоснованно выбирать, что делать.2,93%
2 июл.Я не давлю. Я пытаюсь опереться.2,84%
18 февр.без подписи2,57%
9 мар.Так сложилось, что за последнее время мне довелось неоднократно полежать в стационарах разных больниц. В первый заход всё происходящее казалось сложным и непонятным, куча людей в больничной одежде приходят, что-то с тобой делают, одна женщина втыкает капельницы, другая приносит таблетки, третья приносит еду... И сходу непонятно к кому и с чем обращаться, кто за что отвечает. Наверное, у меня уже какое-то когнитивное искажение сложилось, так что я невольно раскладываю происходящее вокруг меня на части. Говоря системным языком - пытаюсь понять какова архитектура происходящей деятельности. Разобравшись, я искренне восхитился, как четко и разумно оно устроено. Честное слово, есть чему поучиться. Итак, для простоты пропустим приёмное отделение и посмотрим, как устроена жизнь в стационаре. Я выделил вот такие подсистемы: 💊 Подсистема лечения - самая главная часть, вокруг которой крутится всё остальное. Делает так, чтобы каждый пациент получил правильный диагноз и правильное лечение. Тут работают врачи и ординаторы, они выполняют первичный и регулярный осмотр пациентов, составляют план лечения и выдают назначения - что должно быть сделано (анализы, исследования, лекарства, процедуры, выписка и т.п.). Назначения записываются в карту пациента и доступны другим подсистемам на чтение. 👉 Подсистема выполнения назначений, её функция в том, чтобы каждый пациент получал то, что должен получить и не получал того, что не должен. Тут первыми стоят медсестры на посту отделения. Они каждый день берут составленные врачами назначения и формируют листочки-директивы для разных подсистем: 1. Кого и в какой кабинет направить/проводить. Листочки с инструкциями раздаются пациентам, дальше они идут ногами. Кто не может ходить сам - того возят санитары. 2. Кому какая диета показана, этот листочек идет в подсистему обеспечения питания. 3. Кому какие лекарства и в каком виде. Список уколов и капельниц передается в процедурный кабинет. Таблетки раскладываются в таблетницы и медсестры разносят по палатам, дальнейшее исполнение назначения делегируется пациентам. 4. Кого готовить на выписку - этот листочек идет в подсистему обеспечения чистоты, там написано какие постели надо очистить и подготовить к новым пациентам. 💉 Процедурный кабинет, специальное место для выполнения процедур - уколов, капельниц, перевязок и т.п. Для меня стало открытием, что медсестры на посту и в процедурном кабинете имеют принципиально разные обязанности, это разные люди. 🍜 Подсистема обеспечения питанием. Делает так, чтобы каждый пациент получал питание, соответствующее диагнозу и состоянию. Работник службы формирует наборы питания в соответствии с назначенными диетами и развозит по палатам. И если у тебя назначен нулевой стол, то выпросить котлетку не удастся, даже если очень хочется. Ты, конечно, можешь сходить в буфет на первом этаже и сожрать всё, что душа просит, но тогда ты сам себе злобный буратино. 🧹 Подсистема обеспечения чистоты в палатах. Тут все предельно просто. Работники этой подсистемы регулярно проходят по палатам и проводят регулярную уборку, вынос мусора и т.п. Ну и перестилают постели после выписки пациентов. Это наверняка не исчерпывающий список, наверняка есть еще, как минимум, какие-то механизмы по работе с операционными, но с ними я, к счастью, не сталкивался. продолжение следует...2,45%
9 мар.Иллюстрация к посту. Примерно вот такая схемка получается.2,35%
31 дек.Друзья! Поздравляю всех присутствующих с наступающим новым годом! Желаю всем в новом году здоровья, счастья, интересных встреч и удивительных событий. Обязательно научиться чему-нибудь новому и забыть что-нибудь старое 😊. С Новым Годом и до новых встреч! 🎄🎄🎄2,31%
3 февр. 2025 г.без подписи2,14%
4 авг.Мне жена как-то сказала, что только в зрелом возрасте осознала трагедию сказки о рыбаке и рыбке. Давайте представим в красках. Приходит как-то старик и говорит своей старухе, что вот, дескать, словил золотую рыбку, предлагала она всё что пожелаешь, а он отпустил её, плыви, дескать, ничего от тебя мне не надо... Старуха, услышав такое, дар речи потеряла. Напомню, они 30 гаком лет живут они в грязной землянке, в бедности и отчаянии, никаких просветов на горизонте. А ему, видите ли, и не надо ничего! Говорит она ему в сердцах: ну ты вообще разум потерял что ли? Ничего, говоришь, тебе не надо? Блин, да хоть корыто попросил бы! Старик послушал, и что сделал? Он пошёл и попросил корыто! И тут уж бабку разорвало и понесло.. Короче, нет повести печальнее на свете, чем повесть о попытках мужчины угадать желание женщины... Шутки-шутками, а я эту историю вспоминаю всё чаще, когда прошу Клода сделать что-то посложнее, чем написать код. Эта железяка, безусловно, сильно умнее многих ловцов золотых рыбок, но глядя на результат его деятельности невольно ощущаешь себя старухой из сказки. Вроде говоришь ему нормальным языком - вот тебе вводные, структурируй и напиши внятный текст. Боже, какую муть оно выдаёт. Причем, все формальные признаки соблюдены, требования, условия - всё написано, предельно подробно и аккуратно. Только почему-то стыдно людям показывать. И непонятно, что надо этой железяке сказать, как её научить, чтобы результат меня устраивал. Всё таки придется самому писать, это будет быстрее, чем промт оттачивать. А вот код даже на не очень подробных формулировках этот зверёк пишет не очень плохо, по крайней мере, результат не так бесит. Интересно, почему так?1,94%
11 июн. 2024 г.#метафоры Чем круче джип - тем дальше бежать за трактором У любой архитектуры есть пределы развития. Как бы хороша ни была архитектура, со временем она устареет и систему придется заменять полностью.🏗️ 🚜Чем более продуманная и хорошо проработанная архитектура у вашей системы, тем дольше система остаётся в строю и продолжает приносить пользу, адаптируясь под изменения окружения, железа, требований и т.п.🚚 🤔Неожиданный вывод. Чем более древняя, устаревшая, ни на что, казалось бы, не годная система находится в эксплуатации, тем лучше её архитектура. Была бы плохая - её бы давно списали.💣 Вот так вот...1,47%
10 мар.(продолжение рассуждений про больницу) Что мне тут понравилось, что беру на заметку. 1. Четкое разделение труда, понимание кто и за что отвечает. Врач делает назначение, записывает его в карту и он уверен, что назначение будет выполнено, не бегает ни за кем и не проверяет, а правильно ли отсыпали таблетки и не забыли ли сделать укол. Впрочем, бывали случаи, когда врач на словах назначение озвучивал, но забывал отразить его в карте. В этом случае в процедурный кабинет назначение не попадало. В такой ситуации проходилось "решать инцидент вручную" - звонить врачу, уточнять и корректировать назначения. 2. Память системы, вместо памяти отдельного человека. Медперсонал работает посменно, бригада медсестер меняется каждый день. Но вся важная информация, все назначения отражены в карте. Каждый пациент каждый день получает свои индивидуальные назначения, независимо от того, кто именно сейчас на смене. 3. Относительная независимость подсистем, связанность через четкие "контракты" - назначения врачей расползаются по другим подсистемам по понятным, отлаженным каналам. Это дает возможности, например развития отдельных подсистем без влияния на другие: новые средства уборки, замена оборудования в процедурных, обучение врачей. Впрочем, зависимость между подсистемами, безусловно, есть - исполняющие подсистемы должны быть способны выполнять назначения врачей (быть обеспечены соответствующими лекарствами, оборудованием, квалифицированным персоналом). Ну и врачи из множества возможных назначений, вероятно, выбирают те, которые отделение, как система, способно выполнить. 4. Разделение труда позволяет при случае четко идентифицировать, на каком этапе и что пошло не так и внести коррективы - заменить назначение или оборудование в процедурном кабинете. 5. Очень высокие требования к компетенциям и качеству работы на каждой роли. Никакой гениальный врач не поможет, если медсестра не умеет ставить уколы, санитарка плохо моет полы, а выданное питание не соответствует ситуации. При этом медсестра даже самой высокой категории без назначения врача шагу не сделает. У каждого своя работа и своя ответственность. Больница - это место, где, несмотря на четкое разделение труда, важна слаженность и взаимное доверие. 6. Когда каждый точно знает свою зону ответственности, команда в целом работает быстрее и надежнее, ведь каждому индивидуально становится "некуда спрятаться". Чёткое разделение делает работу одновременно сложнее (эдакая "бразильская система", как в старом Ералаше: ты точно знаешь, что никто кроме тебя твою работу не сделает, отступать некуда, позади Москва витрина), но одновременно и проще (не нужно кидаться делать то, что не твое, ты знаешь, что всё учтено и будет сделано). В нашей ИТ-шной реальности мы часто видим обратную картину - все сложно, непонятно, границы ответственности размыты, все хватаются за все, под вывеской командной ответственности никто до конца не отвечает ни за что. Результат предсказуем: все "в мыле", пациент в коме, а что с этим делать - непонятно. В следующий раз, когда будете организовывать команду или проект, попробуйте нарисовать подобную структуру вашей деятельности - кто "диагноз ставит" (принимает решения), кто "назначения выполняет" (реализует), кто за какой результат отвечает. И главное - как информация передается между ролями, чтобы ничего не потерялось. Это непросто, но очень полезно. P.S. Я тут декомпозировал деятельность только одного отделения вокруг одного пациента, а в масштабах больницы всё, наверное, сильно сложнее и гораздо интереснее. Где-то там есть подсистемы выполнения анализов, а каждый кабинет типа УЗИ или рентгенографии функционирует как отдельная подсистема с входящими очередями задач. Для интересующихся для развлечения и расширения кругозора рекомендую книгу "Клиника: анатомия жизни" Артура Хейли, там интересно и живо расписана работа клиники. Книжка уже старая, но интересная.1,30%
22 мар.Неуловимо напоминает "основной закон органической химии". Если смешать бочку мёда и бочку говна - получится две бочки говна...1,19%