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

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

А экономические потери компенсируют ударным трудом и сокращением праздников в мае и октябре. И ослаблением юаня.

-конец блока диванной экспертизы-

“Friends don't let friends use cloud hosting”

Напомнили про эпичный баг в твиторе, который один в один повторяет телеграмный. И это по идее должно побудить корпорации что-то сделать с 2FA авторизацией и как минимум сделать емейлы опциональными. Но нет, этого не будет. И даже после новых рекомендаций NIST, в которых, по слухам, MFA via SMS будет явным образом запрещена.

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

Например, для продуктов enterprise-рынка почти обязательной фичей является поддержка ActiveDirectory. Но некоторые клиенты не используют AD, поэтому нужна поддержка других конкретных LDAP-серверов. Сразу можете забыть про абстрактный LDAP, это не работает в реальности. И вот вы такой умный сделали всё, а тут приходит клиент, у которого пятьсот тысяч LDAP-групп и тысяча пользователей… Или у которого вся иерархия построена не на группах, а на OU… И всё разваливается полностью. Люди в дизайне LDAP проявляют дивную фантазию.

Рекламная компания Гугол опубликовала отчёт за 2019 год, доход от Google Cloud составил 8,9 млрд долларов, а доход от рекламы — 134,811 млрд. (Для сравнения, амазон на облачных сервисах заработал 35 млрд.)

Всего гугол заработал 161,857 млрд., что на 25 млрд. больше результатов 2018 года.

Товарищ выдвинул теорию, что случится, если все крупные американские компании (google, amazon, facebook, apple, microsoft) одномоментно перестанут нанимать людей: зарплаты обрушатся до среднего уровня, поскольку уровень зарплат держится на таком высоком уровне исключительно из-за конкуренции, которую создают перечисленные компании, нанимая постоянно огромное количество людей. Ну и ещё выдвигает несколько теорий, как эти компании могут пользоваться своим монопольным положением на рынке труда.

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

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

Системная инженерия, которую мы заслужили.

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

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

Системная инженерия занимается только рукотворными и материальными системами. Под словом материальный понимается система, занимающая некоторый объём в пространстве и времени. Например, клавиатура, на которой я набираю текст; монитор, на котором я вижу этот текст; новогодний корпоратив, на котором я был в конце декабря 2019 года. Первые два примера обычно воспринимаются адекватно, а насчёт третьего возникает сразу вопрос: а как может быть событие материально? А вот так, оно удовлетворяет всем требованиям: занимает место в пространстве (пансионат «Весёлая белочка») и времени (27 декабря, с 18:00 до 24:00), мероприятие однозначно рукотворное — некие конкретные люди его подготовили, провели и потом ликвидировали.

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

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

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

Да, нужно отличать системное мышление от системной инженерии. Предметом интереса системного мышления являются вообще любые системы, не только рукотворные.

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

А теперь, что такое архитектура. В ISO/IEC 42010 дано такое определение:

fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.

Эта фраза очень компактная и её нужно разобрать отдельно буквально по словам.

fundamental означает, что там не абсолютно обо всём в системе, а только о самом важном и существенном.

concepts or properties of a system означает, что поддерживаются равноправно два подхода: концептуальный, то есть архитектура как ментальная/концептуальная модель в мозгу, и архитектура как воспринимаемые свойства системы.

in its environment означает, что система всегда рассматривается в окружении, то есть среди или внутри других систем.

embodied in its elements, relationships, and in the principles of its design and evolution означает, что концепты и свойства заключены в следующих вещах: элементы, отношения (как между элементами самой системы, так и элементами извне), принципы их (элементов и отношений!) создания и развития.

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

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

Программерское собеседование — это отдельный скилл, который слабо пересекается с обычной ежедневной работой программиста. К такому собеседованию надо готовиться. Если вы идёте на ублюдочные экзаменационные собеседования в стиле гугла/амазона/яндекса, то нужно готовиться по сайтам типа leetcode. Если идёте на нормальные собеседования, то всё равно нужно готовиться.

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

Во-вторых, вы должны наизусть знать базовые алгоритмы типа quicksort. Особо подчеркну, наизусть. Времени их вспоминать не будет.

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

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

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

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

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

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

Современность требует современных решений.

- Во, так получаем примерно 3-4 тысячи ботов на IoT. Тренируем их на таргет, скармливаем им правильный вывод страницы покупки, варианты неправильных, делаем связи между неправильными выводами и причинами, делаем сценарии. Для управления и тренировки юзаем три джаббер канала - один для отдачи команд, другой для ответов типа "статус", третий для ответов по задаче. Нужное файло кладем на крупные порталы для художников, типа девиантарта, завернув в джипег - там обычно канал на отдачу окей и секьюрити хуи пинают.
В назначенный день боты группы А волнами заходят на сайт и чекают страничку, с разными юзерагентами, на предмет изменений. Если изменения есть - сразу пробуют бай, если бай не прошел - репортят об этом во второй чат, оттуда уже джаббер-бот кидает в первый чат команду группе ботов Б, они начинают сайт волнами ддосить сином и смурфом, причем делают из себя сеть для прохождения смурфов на 1000-2000 узлов, получается эффективно. В паузах между атаками четко заходит первая группа и пробует бай, под разными юзерагентами, если бай все же прошел - репортит во второй канал и в третий выдает результаты. Если на сайте вылезает что-то новое, чего не было во время обучения ботов - то тоже кидает в третий канал, чтобы оператор успел вовремя среагировать и поменять профиль атаки.
- Эээ, напомни, а зачем это все?
- Покупаем лимитки сникеров и всякие supreme box logo hoodie для перепродажи.
- ...

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

В ИТ-образовании идёт явный перекос на кодинг и алгоритмы, всё остальное вообще не фокусе массового внимания: тестирование, архитектура, процессы, техподдержка и документация. При этом кодеры занимают ну процентов двадцать всей рабочей силы по моим оценкам. В последние годы немного выдвинулись operations (даже не знаю, как это по-русски адекватно называть, «сопровождение», наверное), но тоже с уклоном в программирование-кодинг (“devops”).

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

«Индустрия ИТ» по факту вообще не является инженерной индустрией, а остаётся ремеслом.

Одно из ключевых понятий в системной инженерии — жизненный цикл (life cycle). Концепт достаточно простой и обычно все его сразу схватывают: жизненный цикл — это стадии, через которые проходит жизнь системы. При этом для систем из разных предметных областей жизненные циклы примерно одинаковые, их общую структуру можно описать так:

рождение → жизнь → смерть

В каждой конкретной системе эти элементы разбиваются на более точные фрагменты. В стандарте ISO/IEC/IEEE 24748-1 приводится очень информативная табличка с примерами жизненных циклов в разных областях.

https://twitter.com/bitfield/status/1225694437482721282?s=20

Очень рекомендую подписаться в твиторе на этого товарища, он постит очень толковые ссылки (не копии с HN) с очень толковыми комментариями.

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

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

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

И когда начинаешь выводить этот концепт в плоскость осознанного сознания, возникает главный вопрос: А что же такое роль? Сразу же возникает идея, что роль — это набор «поведений», «взаимодействий», «реакций». И тут же возникает другой вопрос: А тогда получается, что любой человек (его поведенческая «проекция», аспект) в принципе только из ролей состоит? Мы всё время играем какую-то роль, сила актёров как раз в том и состоит, что они это осознают и поэтому играют эффективно. Они не притворяются, они действительно переключаются полностью в новый режим, полностью меняют поведение, реакцию и действия. Именно этого и нужно добиваться обычному человеку в обычной жизни.

Ну и под конец несколько примеров, хотя обычно именно с них всё начинается. Возьмём человека, скажем, Иванов Иван Иванович (ИИИ), это совершенно конкретный индивидуум, родился когда-то, где-то, прошёл через этапы «жизненного цикла» и продолжает их проходить. Какие роли играет ИИИ в жизни? Например, в семье_1 он выступает в роли мужа и отца. А в семье_2 — в роли сына. В поликлинике_1 он играет роль главного врача, а в поликлинике_2 — пациента (он там лечит зубы). Семья_1, семья_2, поликлиника_1, поликлинка_2 — это конкретные физические системы, играть роль можно только в них, нельзя исполнять роль в абстрактной семье, так как это вообще непонятно что. Очевидно, что для каждой из ролей требуется совершенно разное поведение. Однако это вот очевидно только на конкретных примерах. В других ситуациях без осознанности роли это совсем не так просто.

Возьмём для примера организацию, в которой работает Петров. У Петрова есть должность, он старший инженер-программист. Петров выступает в роли_1, когда он работает в отделе программирования и в роли_2, когда работает в отделе тестирования. Я специально выбрал такие абстрактные названия для ролей, чтобы подчеркнуть их внешнюю нечёткость. В такой постановке ситуации (когда мы роли разделили) уже становится понятно, что в них нужно вести себя по-разному, нельзя паттерны поведения из роли_1 использовать в роли_2. Например, в отделе программирования могут быть свои внутренние процессы, а в отделе тестирования свои, поэтому нельзя рассуждать в одном отделе, используя паттерны другого. Как минимум вас не поймут и вы не сможете договориться.

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

Тормознутость софта в банкоматах переходит все разумные границы. Это что-то запредельно кошмарное. Интервал между нажатием и реакцией часто одна-две секунды. Я пинкод не могу набрать быстро, так как нажатия «схлапываются», и должен после каждого нажатия смотреть на экран и ждать появления звёздочки. А если к этому приплюсовать тормоза и глюки сенсорных экранов… Тыкаешь на экран и не знаешь, то ли тыкнул недостаточно уверенно, то ли просто всё тормозит.

Это началось примерно год как массово, до этого всё было относительно хорошо, а теперь почти везде стабильно плохо.

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

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