Category: архитектура

Category was added automatically. Read all entries about "архитектура".

404

Зона комфорта

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

Но...

Основная часть работы по созданию чего-либо должна проходить в зоне комфорта. Когда всё знаешь, всё умеешь, всё понимаешь. Если создаёшь что-то вне зоны комфорта — это же учебный проект. Поиграться и бросить. Хороший качественный софт (архитектура, etc) может быть создана только в зоне комфорта создателя.

Одной из целей самообучения как раз и является создание такой зоны комфорта, чтобы она была полезной. Но не надо путать процесс «оттаптывания» зоны комфорта и рабочий процесс. Хороший инженер, занимаясь созданием, должен быть на 99.9% в зоне комфорта. В процессе отладки может оказаться, что из этой зоны надо выйти — но вот процесс создания должен быть комфортным, а не исследовательским.


404

RFC: instant reconnect on VIP migration

В ходе обсуждения проблемы обнаружения переноса VIP, у меня родилась суперидея, и мне интересны её последствия, так что пишу RFC (в оригинальном смысле, request for comments).

Конфигурация:

два сервера, дублирующие друг друга. На сервера выделен virtual IP, который перемещается corosync/pacekeeper между серверами. Все клиенты коннектятся к VIP. В случае дауна VIP переползает на passive сервер, который становится новым active. Клиенты обнаруживают, что соединение закрыто, и переустанавливают его.

Проблема: если клиенты долго не получают никаких данных, то в случае дауна первого сервера, второй сервер не знает, что "где-то там есть клиент, который думает, что у нас с ним есть TCP сессия". Кроме клиента про эту сессию знал только первый сервер, а он сейчас умер.

Как только клиент пошлёт данные, он получит RST и переподключится и всё будет хорошо. Но пока клиент не послал данных, TCP живёт. Если стиль работы клиента таков, что он долго ждёт и ничего не шлёт, то может быть ситуация, что VIP перенесли на живой сервер, а клиенты "мёртвые", потому что не переподключились.

Дополнительная информация: мы знаем, что при переезде VIP у него меняется MAC-адрес, и все клиенты получают grace ARP. Очевидно, что речь идёт про один L2-сегмент, и про directly connected клиентов и сервер.

Идеи: При обнаружении grace ARP клиент посылает fake TCP segment серверу, который:

а) Если номер последовательности (sequence number) соответствует ожидаемому, то обрабатывает его (игнорирует, или даже присылает левый ack).
б) Если номер сегмента не соответствует активному соединению, присылает RST клиенту.

Если клиент получает лишний ack, то он его игнорирует (максимум, слегка кривит TCP из-за duplicate ack).
Если клиент получает RST, то он закрывает соединение и открывает его заново.

Ключевое тут, что если соединение с сервером настоящее, то наш "лишний сегмент" ничего не делает. Если клиент думает, что соединение есть, а его нет, то ему новый сервер присылает RST и заставляет переподключиться.

Наше "приложение" посылает лишний сегмент только если у IP (с которым есть TCP-сессии) поменял mac-адрес, при этом все остальные соединения (с другими IP) остаются unaffected.

Смену mac'а мы можем узнать через netsocket с ядром (мне уже ссылку из debian-users@ дали).
Получить список активных tcp-соедиений с заданным IP мы можем (привет, netstat).
Отправить фейковый tcp-сегмент мы так же можем (привет, hping3). Более того, если мы получили grace ARP, то это означает, что с той стороны уже есть отвечающий IP, который может сделать нам RST на "незнакомую TCP-сессию".

Не решённые вопросы:
а) Как выглядит "безопасный tcp-сегмент"
б) можем ли мы узнать все нужные нам данные (включая номер сегмента)
в) что будет, если мы пошлём пакет с кривым sequence от балды
г) Какая комбинация флагов наиболее безопасно.
д) Будет ли к нам приходить RST.

Альтернативно, пакет можно инжектить локально и заставлять клиента его ack'ать (а ack вызывает RST на кривых соединениях - в этом случае нам не надо угадывать sequence для удалённого сервиса)

Комментарии? Предолжения? Критика?
404

Надломился

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

о цикломатике и тестах

Самая убедительная мотивация снижать цикломатическую сложность функций - это тесты. Если тесты не могут покрыть все случаи функции, значит это не функция, а несколько, слепленных вместе. То есть как только начинаешь думать "как я это буду тестировать" - сразу меняется стиль программирования. Каждый if в коде - это big deal, возможно, даже ещё один тест. Если if'ов несколько, то драма нарастает, ибо надо либо матрицу условий делать, либо кому-то пора резать функцию на несколько.

То же касается и структуры классов (thnx to Дима) - если слишком много моков на инициализацию класса, значит, что-то не так с архитектурой.
404

newgen сисадминство

Пытаюсь уловить витающущю в воздухе мысль: Modern OS has too many moving parts.

Когда мы говорим про админа локалхоста и жизнь ноутбука, да, все нюансики того, как оно там саспендится, как язык переключается, как сервисы стартуют и obsolete или нет файл /etc/foo/bar/baz.xml, который когда-то поменялся post-inst'ом, а теперь это повод для того, чтобы сфейлилась автоматическая миграция на /etc/baz.conf при удалении obsolete-foo и замене его на shiny new atarashi-baz - это всё важно.

Но когда у вас сервера фермами стоят и добрая половина из них, вообще, инстансы виртуалок, есть острое желание закатить глаза и сказать "мне пофиг".

Главное, чтобы одинаково, унифицированно и без нюансиков.

Вот именно "без нюансиков" в современных системах и не получается. Я не говорю, что должна быть кнопка "снять шедевр", просто очень хочется, чтобы у системы не было _состояния_ помимо того, что поменял админ. Осмысленно, а не post-inst скрипт от его имени из лучших побуждений.
404

Архитектурно-философское, про best practice

Часто столкнувшись с слегка нестандартной задачей я испытываю замешательство, потому что не знаю и не могу найти никаких существующих практик для её решения.

Это можно было бы счесть всего лишь "не знаю как делать и не хочу заморачиваться", но внутри я ощущаю что-то более сложное.

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

Таким образом, когда оказываешься в ситуации, когда известной практики нет, ты о существовании практики не знаешь, или существующая практика не подоходит - короче, когда надо изобретать своё, в этот момент, чем больше опыта, тем острее он давит и говорит о том, какие последствия будут. Очень отдалённые и очень неприятные. Ощущение "и чем я думал, придумывая вот эту хрень?", повторяющееся несколько раз, оно очень дисциплирует.

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

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

Вот, яркий пример: ну откуда мимо пробегающий программист знает про систему /etc/nginx/sites-available/ и sites-enabled? Он идёт читать маны от nginx'а, после чего идёт и херачит всё в nginx.conf, а при переносе в продакшен сисадмины только за голову хватаются (иногда от сарказма иногда от того, что не уследили и оно пролезло в продакшен).

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

И в других областях то же самое - я иногда чувствую очень конкретный сарказм у программистов по мотивам написанного мною. И не потому что "плохие алгоритмы", а потому что я не соблюл очевидные (для них практики). А где я про них узнать могу-то?

Вотъ.
404

sudo - Ошибка проектирования

Кстати, команду sudo я считаю одной из очень неудачных по архитектуре.

Скажите, читающие господа-админы, кто из вас знает её синтаксис более-менее целиком? Нифига. Гугль, гугль, гугль. А ведь это инструментарий разграничения доступа! Его должен знать каждый админ?

Итог - ошибочная архитектура, слишком сложная для steady learn (сравните с элегантностью архитектуры ssh, где человек начинает с тривиального ssh user@host, а потом плавно переходит на ключики, туннели, scp, локальный и глобальные конфиги, отзывы ключей и т.д.).

Она ошибочна не по функционалу, а по human-learning-interface (такой термин вообще есть?) - то есть ожидания проектрировщиков программы отличаются от обычного learning pattern пользователей. Это ошибка. Ошибка проектирования, не кода.
404

DBZ (~60)

Оно начинает напоминать OP по формату и сложности сцен, да. Однако, тут есть огромная разница - мир OP более стационарный. То есть DBZ развивается по TTGL'ной спиральке, с постоянным спауном мобов большего уровня и левелкапингом (да-да, левелкапинг изобрели не в WOW) для новых персонажей. Иногда это приводит даже к очевидным глюкам в терминологии "сильнейшего".

В OP же, наоборот, toplevel определён в первых сериях, а дальше идёт долгое и тщательное объяснение, как же охрененен toplevel. И если кто-то на 0.001% его превысит - это будет запредельное достижение. В этом смысле оно сильно напоминает ..."Замок" Кафки, потому что там Замок был с самого начала, и сквозь всю книгу герою объясняли, насколько же он идиотом был, пытаясь туда попасть - происходило это бесконечным разветвлением первой ступени: казалось, до замка три шага, нужно сделать первый шаг - чтобы его сделать нужно сделать три шага - и герой всё время болтался в районе первого шага с бесконечным дроблением. В OP примерно то же самое, только герои не болтаются в первом шаге, а таки лезут на верх, и дробится не первый, а последний шаг. И ощущается, надо сказать, это совсем иначе - в Замке герой всё время сваливался всё ниже и ниже, а в OP он стремится всё выше и выше.

PS Это чем-то напоминает теорию зубочистки у Мураками.
404

Сюжет (аниме по мморпг)

Насколько мы все помним, сделать сколь-либо удачное аниме по реальной ММОРПГ не удавалось никому. В первую очередь потому, что любой создатель "аниме по игре" пытается реализовать сюжет.

А суровая реальность состоит в трёх важных тезисах:
* Сюжета в ММОРПГ нет.
* Если сюжет в ММОРПГ есть, всем на него насрать.
* ММОРПГ интересна не сюжетом.

Отсюда простой вывод - аниме по ММОРПГ должна быть не про ММОРПГ, а про игроков. Никто же не пытается в аниме про бейсбол рассказать про судьбу мячика? Вот так же и в ММОРПГ. Есть игроки. Есть драмы. Есть мотивы. Есть победы и поражения.

Показывать надо _ИХ_.

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

Во-первых, рагна в своём ультимативном воплощении (которого никогда не было и не будет, но которое подразумевается, как идея) - это сложная командная игра, требующая огромной отдачи сил и времени от каждой команды. В каком-то смысле, рагна - это игра в хороший хардкорный спокон. С возможностью таки побыть в шкуре _ГЛАВНОГО_ героя.

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

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

Дальше что? Дальше рост - попытка найти себе цель. Тренировки (и всё ещё интерес - потому что многого не знаешь, и многое непонятно). Случайные пати. Неожиданные смерти. Осознание, что чем ты старше, тем больнее умирать (хаха, эти люди ещё не знают, что такое, слитый процент на 98...).

Вторая профессия - опять познание, опять интересно. Гордость достижением.

И тут заканчивается вторая серия.

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

И осознание, что "всё только начинается". Исследование мира даже не начиналось, как оказывается.

... Основание своей гильдии. С нуля, с самого начала. Через драмы и победы. Уговорить остаться и разрулить конфликт между согильдицами. Решить проблему расходников и навести дисциплину. Позорно слиться в 30 раз в сбанте, зайти всей гильдой в замок с 100 эко и слиться не успев увидеть от чего на первом же гейте.

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

Первое коллективное доение. Экспа. Команда.

Первый настоящий бой. Замок. Не шальной, настоящий. С эко. Набор нубов - разброд в гильдии, второй состав, координация в боях.

Право быть последним в первой десятке. Бои - незначимые и такие важные. Тройка лидеров. Герой - уже не просто герой, а постепенно понимающий суть игры, можно сказать, умудрённый сединами, старик.

Высокая политика - переговоры между гильдиями, альянсы, строящиеся не на силе, а на идеологии. Этический выбор: щемить ли нубов? Сливать ли эко ради слива? Выбор истиного пути гильдии.

92 серии, три мувика и пять ОВА.
404

АМД

АМД в своей никчёмной жизни сделала одно - назвала архитектуру AMD64. I386, но A64. Великое достижение.