Engineering Under Uncertainty

Позната ситуация: трябва да избереш архитектура, технология или посока сега, а половината от нещата, които биха ти помогнали да решиш, още не са известни.

Колко ще бъде реалното натоварване? Къде ще се появи тесният участък? Колко ще нараснат данните? Ще важат ли днешните изисквания след година? Кое от допусканията на екипа ще се окаже грешно?

Проблемът не е просто, че ти липсва информация. Истинският проблем е как да отсееш наистина значимите фактори, кое си струва да провериш, кои резултати могат да се предвидят до определена степен още сега дори без знание за бъдещето.

Това умение става още по-важно с AI. Имплементацията става все по-бърза и по-евтина, но добрата инженерна преценка не се автоматизира толкова лесно. Колкото по-бързо можем да строим, толкова по-бързо можем да построим и грешното нещо.

Науката се занимава със сходен проблем от векове: как да стигнем до надеждно заключение, когато наблюденията са оскъдни, измерванията са шумни и правилният отговор не е известен предварително.

В този практически 3-часов уъркшоп с насоката на д-р Константин Гиздов ще работим върху начини да ограничаваме неизвестното, да оценяваме мащаба, да проверяваме собствените си идеи и да вземаме защитими технически решения, без да чакаме „перфектните“ данни.

Подходите са вдъхновени от научния метод, експерименталната физика, статистиката и системното мислене, но няма да учим физика и няма да решаваме сложна математика. Ще ги използваме върху проблеми от софтуерната архитектура, cloud, distributed systems, data и AI.

Дори пълната неизвестност има реални граници

Какво можем да знаем, дори когато ни липсва информация?

Когато не знаем точния отговор, лесно е да приемем, че „всичко е възможно“. В реалните системи почти никога не е така.

Ще търсим ограниченията, които вече са известни: ресурси, време, цена, зависимости, бизнес правила и условия, които винаги трябва да останат верни - и най-вече как комбинирайки ги чрез граници, инварианти и еквиваленти можем да свием широк проблем до много по-малко поле от реалистични решения - дори преди първата линия код.

Естимирай преди да избереш

Трябва ли ти наистина Kafka? А Kubernetes? Distributed database?

С оценки от типа на задачите на Ферми ще работим с натоварване, брой потребители, обем данни, пропускателна способност, време за отговор и цена.

Не търсим точност до втория знак след запетаята. Търсим порядъка: При какъв мащаб сегашното решение действително спира да бъде добро?

При какъв дъжд ще падне къщата?

Вместо да доказваш, че идеята ти е добра, опитай да откриеш кога ще се счупи.

Много по-лесно е да се влюбим в архитектурата си, отколкото да търсим активно причините тя да е грешна.

Ще разглеждаме техническите решения като хипотеза:

Допускане → предвиждане → проверка → наблюдение → решение  и ще видим как това помага при прототипи, spikes, ADRs и evaluation.

Бъди готов за проблеми, които дори не може да предвидиш

Как проектираме система така, че да можем да разберем какво се е случило дори при ситуация, която не сме предвидили предварително?

Дизайнът ни трябва да помогне да отговорим на трудния въпрос: „Какво, по дяволите, се случи?“

Всеки компонент трябва да си заслужи мястото 

Кога сложността е необходима и кога просто overengineer-ваме?

Всяка queue, cache, service boundary, abstraction или нова технология има цена.

Ще използваме прост въпрос:

Кое конкретно изискване налага тази сложност?

И ще видим как да променяме техническите си решения, когато ново наблюдение покаже, че първоначалните ни разбирания вече не са валидни.

Уъркшопът се провежда онлайн, без запис.