промкомплекс

На самом деле никакой это не манифест.

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

Я на протяжении своей инженерской жизни (не такой уж длинной, но какая есть, хуле) временами ловлю абсолютно тупые косяки с проебом времени, ресурсов и нервов, которые проистекают не из проблемы хардскилов, а из-за некорректного образа мысли, e.g. построить сложную архитектуру с нуля, а не поэтамно переходя от сложного к простому. Или, например, забить на мелкий косяк в логах, который постоянно мелькает в контексте проблемы потому что он кажется нерелевантным (нет, блядь, он релевантный. А сейчас дочитай манифест, а потом пойди и займись процессом поиска связи этого мелкого косяка с общим контекстом проблемы)

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

Как соберется нормальная стопка заметок - издам книжку лет через 30, если доживу.

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

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

Engineering manifesto

Handle Exceptions and errors. ALWAYS.

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

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

In distributed systems, suspicion, pessimism, and paranoia pay off.

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

Use single data source, make sure that there is no hidden cyclic data dependencies. Make sure that data flow does not contain any sort of cycles.

А вот это достаточно забавный случай, который я отловил за пару часов. Но само решение кейса заняло около месяца и два раза требовало рефакторинга (считай два-три дня в сумме проебал, работаю я обычно часов 10/день)

Всегда рисуй граф потока данных. В нем не должно быть циклов, даже если это кажется безопасным. О каких циклах идет речь? Речь идет когда Узел А на вход может получить данные из узла Б, а узел Б всегда отправляет выходные данные в узел А. Казалось бы - выглядит такая схема эволюции данных бредово, но это до тех пор, пока у нас абстрактные кубики с буквами внутри.

К сожалению, конкретные детали уже не вспомню. Если хочешь более формализованную информацию - гугляй Acyclic Dependencies Principle и Unidirectional Data Flow.

The engineering of low-latency systems is a discipline of removing abstractions.

Тут мне сказать нечего, это просто аксиома.

Про легкие задачи

The second reason is that DevOps seems to be particularly susceptible to yak shaving. If you haven’t heard of “yak shaving” before, I assure you, this is a term that you will grow to love (and hate). The best definition I’ve seen of this term comes from a blog post by Seth Godin:

“I want to wax the car today.” “Oops, the hose is still broken from the winter. I’ll need to buy a new one at Home Depot.” “But Home Depot is on the other side of the Tappan Zee bridge and getting there without my EZPass is miserable because of the tolls.” “But, wait! I could borrow my neighbor’s EZPass…” “Bob won’t lend me his EZPass until I return the mooshi pillow my son borrowed, though.” “And we haven’t returned it because some of the stuffing fell out and we need to get some yak hair to restuff it.” And the next thing you know, you’re at the zoo, shaving a yak, all so you can wax your car.

Золотая цитата, из книжки Brikman Y. Terraform. Up and Running.

Always set maximum restrictions to bash scripts. Check that your cloud runners have

set -euo pipefail

in your scripts and in parent runner context.

even if you handle errors with pipefail - explicitly check for error codes in if conditions and sub-functions. errexit does not monitor for errors in those structures. link with sacred knowledge.-,inherit_errexit,-If%20set%2C%20command)