татко Крокодил

Преди известно време NSA разсекретиха лекция, която (по това време капитан, после адмирал) Grace Hopper изнесла при тях през 1982 година. В тази лекция има много интересни неща и я препоръчвам на всички да я изгледат, но една част от нея ме побутна да направя моята.
(всички, които гледат лекцията почват да искат да имат баба като нея)

(ако някой не знае коя е Grace Hopper, силно препоръчвам да се се зарови)

Явно се сблъска в главата ми с много други неща, свързани с “мениджмънт”, “човешки ресурси”, “модерно робство” (за мен термина “човешки ресурси” е наследство от времената, когато робството е било нормално. Честно казано, даже очаквах да намеря някой римски термин като “Homo subjecto” (човекопредметност), на който да е наследство).

Та поне аз имам нужда да разкажа какво знам за правенето на екипи, поддръжката им, работата с тях. Вижда ми се много по-важно от всякаква техническа тема, на която бих могъл да говоря в момента, и съм зарязал поне три такива полунаписани лекции, за да направя тази.

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

Тази лекция събира опита ми от последните двайсетина години с някакво количество книги, изчетени по темата. Опитът ми е от различни фирми (последната е StorPool), и доброволчески организации като OpenFest, FOSDEM, IT турнето и разни други.

Този въпрос го има и накрая.

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

Едно от нещата, които ми е липсваше в университета (и което се стараех по някакви начини да вкарвам в преподаването си там) бяха екипни проекти. Възможно е това, че аз съм бил три години втори курс да ме е спряло да открия, че всъщност се преподава екипност, но и на разглеждане на конспекта такива неща няма – всички изпити, контролни и други подобни забавления са индивидуални. Единственото отборно нещо, в което съм участвал беше едно състезание по програмиране.

HR отделите това им е част от работата, но в повечето случаи не им се получава. Всички екипи, които съм виждал са супер подозрително настроени към всякакви подобни инициативи.

Също така, много ще се радвам, ако след лекцията хората ми кажат, че това са неща, дето се знаят и съм и загубил времето.

Малко spoiler alert за какво ще говоря – за как се събира екип, за какви хора бихте искали и каква култура, как може да работи, и как се поддържа.

Този слайд го има основно, за да си изяснят хората дали ще им е интересна лекцията, и да ходят да пият/пушат отвън, ако не :)

Малко източници, на които съм се базирал.

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

Военните организации са друг интересен пример. Теорията им съществуват от много отдавна, и при тях доста от лошите идеи са отмрели (понякога съвсем буквално). Доста от техните идеи са неприложими извън тяхната сфера (например принципите им за team building са незаконни), но има и много полезни неща.

За системите от хора (т.е. организации) има също написано много, ще се появява на разни места из лекцията.

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

Да започнем с това как се събират правилните хора.

Виждал съм и познавам хора, които са или водещи екип, или важна част от него, но отказват да се занимават с взимането на хора в него. Считат го за скучна, второстепенна или направо ненужна част. Има и фирми, в които самите екипи почти нямат право на глас кой влиза в тях.
И двете не са правилни, съответно силно ги препоръчвам на всичките ни конкуренти.

Хората, с които работите определят дали ще си свършвате работата, дали ще ви харесва, или сутрин ще трябва да си разреждате кафето с нещо по-спиртно, за да може да понесете деня.
(Личен съвет – ако откриете, че започвате да си сипвате алкохол от сутринта, за да може да си вършите работата, е време да напуснете. Както и ако в понеделник сутрин ви става лошо при мисълта, че трябва да ходите на работа)

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

Ще базирам тази част основно на какво правим в StorPool, но доста неща са подобни и при търсенето на доброволци, и твърдя, че са приложими за повечето IT специалности.

В StorPool ни отне време да изгладим процеса (и сигурно има неща, които допълнително можем да подобрим). Това не стана без да направим едно количество грешки.

Първия път пуснахме обява по нормалния начин, видяхме 20-30 CV-та, от тях избрахме 10 по някакъв начин, и ги поканихме на интервюта.
След като приключихме с тях (отне около седмица), седнахме, поговорихме и си казахме “NEVER AGAIN”. Обърнахме процеса, като сега първо пращаме на кандидата задачи, и след и ако реши някаква част от тях, каним на интервю.

CV-тата на хората дават идея за какво да си говориш с тях. От там нататък стойността им не е особено голяма – хората лъжат, доста често ненарочно, и разликата между двама човека със същото CV може да е от земята до небето. А интервю с грешния вид човек е изпитание и уморително упражнение, което спокойно може да се пропусне.

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

Та, един ден седнах и насъбрах задачи. Спомних си някакво количество проблеми, с които съм се борил и които са ми останали в главата, малкото код или други неща около тях, и сглобих нещо, което лесно да даваме на хората да решават.
Това, че съм ги запомнил има и друго предимство – че вероятно са интересни. Ако карам някого да ми отдели някакво време, е добре да не е с нещо скучно :)

Важно е задачите да са реални. Това има допълнителния момент, че кандидатът може да разпознае неща, с които се е борил и да разбере, че не е сам :)

И разбира се, трябва някакво разнообразие, не може да дадем същата задача 5 пъти с различни параметри. Най-малко никъде работата няма такова нещо.

Задачите са прекрасен филтър.
Има хора, които изобщо отказват да обърнат внимание, защото смятат, че са над такива неща. Има хора, които не намират подобни неща за интересни. Има такива, които не могат да решат нищо от тях. И наскоро дори имаше случай “не смятам, че някога в реалната работа ще ми се наложи да правят A и B (неща от задачите).

Последният не е прав, а всичките други групи са хора, които не бих искал в екипа си.

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

Смятам, че човек трябва да се занимава с неща, които му харесват. Може би не всички детайли, но основната част от работата, генералната цел и каквото се постига, трябва да са нещо, което ти харесва. Животът е твърде кратък, за да се занимаваш с глупости.

Това, освен че прави целия процес на работа по-приятен, води и до това, че се работи с по-кадърни хора. Колкото повече ти харесва нещо, толкова повече влагаш усилия и се занимаваш с него и ставаш по-добър (всички сме чували за 10те хиляди часа).

И разбира се, ако хората им харесва, няма да искат да си тръгнат. Достатъчно често попадам на случаи, в които хората искат да напуснат и да идат някъде дори на по-ниска заплата. От друга страна пък, никога няма да забравя как се опитвахме да подмамим при нас Боби Станимиров. Бяхме го завели на обяд в едно много приятно заведение, говорехме си, обяснявахме колко интересни неща правим, и той в един момент каза “Да, вашето е интересно. Ама при нас лекуваме рак.”
(той тогава беше във viewray, те правят комбинация от ядрено-магнитен резонанс и гама-нож, т.е. докторите могат да гледат докато режат с гама ножа)

Да си харесваш работата всъщност не е толкова рядко, а хората харесват какви ли не работи. Може би най-простия пример, който имам е как хора ходят, учат във ФМИ и вместо да след това да работят за много пари в IT-то, стават учители – професия, която (да цитирам един мой любим сериал) комбинира стреса на неврохируг със заплащането на продавач в магазин.
Шапка им свалям на тези хора, аз не бих могъл.

(или всички доктори)

Слайдът, разбира се, може да се чете като “отклонение е да си харесвате работата”. И такива отклонения трябват :)

Благодаря, че ми намериха този графит, който беше написан едно време, мисля на ул. “Париж”, и който е донякъде крайната фаза на харесването на работата и мотивираността. Поне според мен, човек трябва да може сутрин да си отговаря на този въпрос или с “да”, или с “ще направя нещо, че отговорът да е ‘да'”.
(предполагам не е полезно да мислиш за умиране всяка сутрин, та може да бъде разредено кога се преосмисля, но принципът си остава :) )

Чудил съм се понякога колко е наемът на един билборд на Орлов мост, за да сложим този надпис да постои там известно време.

Човек и добре да живее, трябва да си говори с други хора. Процес на наемане без интервюта няма как да се направи.

Виждал съм различни варианти на интервюта. Може би най-любимото ми беше в google, където им бях на гости за един ден, сложиха ме в една стая и различни екипни lead-ове ме разпитваха в продължение на около 5-6 часа.
(може би заради това Дъблин ми стана другия любим град след София)

Това идва тежко за доста хора, и е отделяне на много време с неясно каква полезност. При нас базовото техническо интервю е едно, с двама-трима човека от наша страна. Имаме няколко области, в които задаваме въпроси, като цяло съвсем стандартно.
Различното е, че цялото интервю започва с обясняване кои сме ние, какво правим и каква е работата. През целия процес на интервюто идеята е не само ние да научим нещо (за кандидата, или като цяло), но това да се случи и за отсрещната страна. Всяко интервю трябва да е полезно и за двете страни, и да помогне за отговора дали наистина искат да работят заедно.

После срещаме човека с целия екип, с който ще работи. Всеки има право да знае в какво се забърква, а и помага да видиш, че ще работиш в компания на сродни души (или ужасни изроди и по-добре да бягаш надалеч).
След срещата на целия екип въпросът, който си задаваме е “Кажете нещо лошо за човека”. Ще го спомена по-долу, но да почна от тук, решението за нов човек се взема с консенсус – всички от екипа участват във взимането на решението и трябва да са съгласи за новия член. Тези интервюта са едно от много малкото неща, за които занимаваме хора, излезли в отпуска.

И има едно “човешко” интервю (все ми се карат, като го наричам така, та приетия термин е “не-техническо”). Целта му е да хване проблеми с човека, които ние не сме видели.

Всички преди изпитателния срок е филтър, който да намали хората, провалящи се в него. А самият изпитателен срок е правилният показател дали може да се работи с някого.

Един от любимите ми процеси за интервюиране беше в Automattic – там имаше едно-две интервюта, и после директно едномесечен договор, в рамките на който ти дават достъп, правиш задачи с разни хора за разни цели (истински задачи, има шанс едно от нещата дето правих да са го ползвали прилично време) и двете страни могат да видят как изглежда работата и вписването на новия човек. Завиждам на фирмите с достатъчно ресурс, които могат да го правят.

Учудващо, разликите в доброволческите организации са основно в реда на случващото се. Много често доброволците директно почват с един изпитателен срок, преди да навлязат повече в организацията :)

Практически обаче, има горе-долу същите стъпки и действия, за да стане някой част от доброволческа организация – да свърши нещо, да се срещене с някакви основни хора, и после с всички, и да работи с тях известно време. На практика много от доброволците минават като първа стъпка нещото със “задачите”, понеже идват един ден и някой им казва “свърши това” :)

Това е като продължение на частта с типа хора, който искаш.

За да работи един екип, трябва да съществува в добра среда. Среда, която насърчава правилните неща, не толерира вредните, и дава възможност на хората да се развиват и да работят.

Културата е нещо, което съществува в екипа, но трябва да е подкрепено на всяко едно ниво.

И понеже това е някакво вятърничаво като обяснение, ето конкретни примери.

Един пример, който ще дам, е FOSDEM и open-source решенията. Видеото на FOSDEM винаги е било с open-source решения, доколкото е възможно, и когато е имало възможност да се направи още нещо отворено, като например смяната на един capture device с друг, това винаги е било подкрепяно от цялата организация, въпреки отражението върху бюджета на събитието. Това винаги е важало и за всичко, което се ползва – ако има възможност, се прави с open-source софтуер, ако ще и самата организация да си го напише, без възражения от типа “не можем ли да ползваме онова готовото и да не се занимаваме”.

Друг пример – за нещо, което не осъзнавах, че е добре да се формализира – е т.нар. blameless postmortem. Идеята е следната – ако се случи грешка, която да доведе до сериозни последствия (в нашия случай – downtime), се пише postmortem документ, който описва как се е случило събитието, какво е довело до него, и какво може да се направи, за да не се случва пак.
Blameless частта е, че вместо да кажем “Пешо пипна там и то се счупи, та ще му хвърлим един бой”, се прави по-трудното – изяснява се процеса, грешката и как да не се стигне пак до там. Така се правят по-малко грешки, и не се стига до там, че хората не смеят да правят нищо, за да не пострадат.
(и това е обратно на културата на твърде много места, които съм виждал)

Свързано с това по-горе, културата трябва да приема, че грешките са нещо възможно, и че са някаква част от learning процеса. Щом това успяват да го приемат в области като медицината и воденето на война (USMC имат изрично записано, че “there must be no ‘zero defects’ mentality”), където заради грешки умират хора, не мисля, че и в IT-то не може да се приложи.

Също така, одобено доброволческите организации трябва и осигуряват възможности за развитие, да можеш да смениш екипа, да видиш нещо от друга гледна точка, и да можеш да разнообразиш. [да се допише]

Това си мисля, че е познато на всички. Ще се връщам към него, но просто ще кажа, че всеки в един екип трябва да може да е Бай Иван, без значение позицията.

Съвсем дискриминационно ще кажа, че има правилни и неправилни хора, с които да работиш.

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

Има много изписано и изговорено на темата как се мотивират хора. Преди години един колега беше попаднал на статия, която възприехме, и която казваше, че ако хората не се мотивират сами, то насила няма как да се получи добър резултат.
(“насила админ не става”)

Аз не мисля, че мога да мотивирам някой, който не би могъл да се мотивира сам (и определено не искам). Мога да покажа работата, да обясня какво е интересното, какви неща никъде другаде не правят (или в случая на доброволчеството – какво постигаме), но всичко това е безсмислено, ако човекът не е достатъчно self-driven, за да може сам да се мотивира и да се движи напред.

И да натъртя още веднъж идеята, ще дам пример за едно обяснение към студенти, как по партита като се забиват с някой от подходящия пол, преди секс да не търсят “consent”, а “entusiasm”.

При доброволците има важен момент, който следва от предното. За да си харесваш работата и да си достатъчно желаещ да се занимаваш с нея (особено за без пари), трябва да го припознаеш като нещо свое. И това е едно от най-важните неща в подобни организации – да събере хора с обща цел, които приемат целите на организацията за свои.

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

Така и обратната връзка не се приема като нещо лошо, а като нещо, което помага да се движите напред. Екипът не трябва да има страх да каже на някой “моткаш се” или “това е грешно”, какото и всеки в екипа трябва да е ок с подобен feedback. Ако сме се подбрали правилно, нищо от това не е с цел да тормози другия, а с цел да си свършим работата.

Та може би поговоркара за сговорната дружина може да е “дружина с обща осъзната цел планина повдига”, понеже съм го виждал в действие :)

Крис Хадфийлд, който първо ми беше познат от една глава на “How to” (на темата “как да приземим космическата совалка на различни странни места”) има една глава в книгата си “An astornaut’s guide to life on Earth”, в която обяснява какво е правилното нещо, към което да се стремиш да си в един екип. Отговорът му е, че винаги поне трябва да си на нула, т.е. да поддържаш нивото на работа на екипа.

Това е нещо, което е трудно за разбиране. Много хора смятат, че могат от първия ден да направят промени, които да подобрят екипа, работата, да им помогнат да се изтъкнат и т.н. После бързо се обезкуражават след сблъсъка с реалността – понеже за всяко нещо в една организация си има причини, и те трябва да бъдат адресирани, преди да се направи някаква (може би голяма) промяна в начина на работа.
(това не променя факта, че е важно да се проявява инициатива и да се подобрява работата на всички)

Това е и истинската дефиниция на “екипен” човек за мен. Като пример как не се прави, ще дам скорошната случка, в която maintainer-а на Rust за linux kernel-а се отказа да се занимава, защото му било омръзнало да го занимават с “нетехнически” проблеми. Което показва колко заблуден е бил, щом е очаквал, че проблемите му ще са само такива – цялото това нещо, което се опитва да направи е като да накара ламята Спаска да танцува балет. И колкото да обяснява колко гениален е тоя балет, има много други подробности, преди това да има шанс да се случи.

Изобщо по темата за убеждаването на хората и прокарването на идеи, препоръчвам лекцията на Грейс Хопър, която споменах в началото. Тя обяснява за добри начини за постигане на промени в подобни обстоятелства (тя все пак е работела за department of defense и други подобни гигантски структури).

Иначе, имало е доста странни въпроси по интервюта, които са ми помогнали да изчистя моето очакване за какво е екипност и какво всъщност очакват хората. Най-странния въпрос, който са ми задавали беше дали сме повече adversarial или cooperative – което за мен беше невероятно, понеже никога не съм бил/очаквал някой такъв екип да е adversarial и хората да се състезават, вместо да си помагат. Предполагам, някъде има приложение, но поне за мен не е в рамките на една организация, която се опитва да върши работа.

Понеже до тук говорих за общите неща в хората, извън тях, останалото няма значение. В разните екипи, в които съм бил и са били ефективни е имало хора от всякаквите възможни части на обществото, по всякакви признаци, и това определено помага да се избегне groupthink-а (или поне да се намали). Дори в текущия ми екип, който на практика е само системни администратори, има следните под-видове хора: бивши военни, тонрежисьори, готвачи, заварчици и т.н.. Ако попаднем на необитаем остров, няма да ни е скучно, няма да умрем от глад и сигурно ще намерим начин да се измъкнем…

А последния link – ако не сте го чели, отделете му 20 минути. Той обяснява колко бързо свикват хората с глупостите в една организация. Заради него ние правим едно post-onboarding интервю с всеки нов човек, горе-долу на втория месец, в което сядаме и започваме да задаваме въпроси от типа “сега, докато още не си свикнал с нашите глупости, кажи какво не ти се вижда вярно”. Силно препоръчвам и като четиво и като практика.
(в началото имаше доста моменти в тези разговори, в които си казвах “а, ама и аз имах проблем с това, и то все още не е правилно”)

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

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

Има една идея (срещана и в много вицове), че решенията идват отгоре и толкова. Това е грешно по две причини – губи се полезния опит на членовете на екипа (които сме ги избирали да са умни хора), и защото така има приличен шанс екипът да няма желание да ги изпълнява – понеже не може да ги разбере, не мога да види, че водят до нещо смислено и може би просто от инат.

Това, което работи най-добре е да се изговори даден проблем и да се стигне до консенсус. За някои неща това е единственото правилно решение (например наемането на нови хора в екипа), въпреки времето, което може да отнеме. Понякога има подобен вариант с rough consensus (който го има разписан в IETF документите), който казва, че в общи линии сме съгласни с някакви резервации, но да действаме е по-добрия вариант, отколкото да продължим да го дъвчем.

И ролята на водещия екипа в такива дискусии (освен нормалното участие) е да сумаризира и да отпушва дискусията, когато забие в някоя ненужна посока. Формално накрая може да произнесе решението и да носи отговорност за него, но то на практика трябва да идва от екипа.

Понякога консенсус не се получава – опциите са много, мненията са различни, има нужда да си подредим по предпочитаност някакви опции. В такива случаи може да се прибегне до някакво гласуване, като обаче е важно да сме наясно с изборите, и как точно избираме. Темата за системите за гласуване е много обширна и няма да се спирам на нея, но препоръчвам на всички да се запознаят с модифицирания Condorcet метод, който се ползва в Debian проекта.

А в някои случаи (по-често срещани в доброволческите организации), под-група казва “това ние можем да го случим и поемаме отговорност”, и това е решението. Това пак помага на организацията да се движи напред и да си върши работата, вместо само да отлага и да не прави нищо.

За да може да се случи последното, трябва правилната култура, за която ще говоря надолу.

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

Нещо важно, което се пропуска (и което продължава да ми е проблем при мен самия) е, че понякога има връщане към стар проблем, и опит да разберем защо сме взели дадено решение и дали не трябва сега да вземем различно. Съответно, е добре да има някъде записани старите доводи.

Ако нямате стенографиращ екип, и не сте водили дискусията по mail, то на практика се разчита само на паметта на хората. Паметта на хората е нещо ужасно (който не го вярва, да прочете “Невидимата горила”). За това всяка организация би трябвало има писмена институционна памет (не само хора, дето помнят някакви неща), за да може да се обръща към нея в такива моменти.

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

Документирането никак не е лесно, но се изплаща многократно.

И тук някъде идва разговорът за воденето на екипа.

По принцип екипите си имат lead в някакъв вид. Дали се води директор, мениджър или какъвто-там-е-термина, в организацията ролята е да бъде интерфейс между екипа и останалата част от организацията.

Това има различни варианти да се направи. Чувал съм, че често е някой, дето да назначават и да размахва камшика без идея какво правят хората “под” него.

В това има няколко проблема, като тръгнем от това, че тези хора не трябва да са “под”, а “при” него. За мен един lead е част от екипа, може да е смислена част от него и може да е “бай Иван”.

Това е един списък, дето написах още в началото, докато си правех плана на лекцията. За мен е сравнително очевиден, но сам по себе си не е особено интересен. Може да се намери в някакъв вид в много книги, включително в голяма част от всичката военна фантастика :)

За мен по-важно е в екипа всяко едно от тези неща да може да го прави всеки, и да има увереността, че може да го прави – може би не от първия ден, не максимално ефективно, но в един момент всеки трябва да може да поема отговорност, и всички да могат да застанат зад него, когато се наложи.

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

Не е задължително да има един lead. Виждал съм (и съм участвал в такива) екипи, където има трима lead-ове, с различни профили. Те донякъде могат да се покриват, но са специализирани достатъчно, и са достатъчно автономни, че да могат да движат нещата без постоянно да трябва да се разбират за някакви неща. Като един пример, това беше OpenFest през повечето време, през което се занимавах с него.

Да има резервен човек, който може да поеме такъв тип задачи е направо животоспасяващо. Това може да е формализирано, а може и просто когато се наложи, да излизат хора от екипа, които да поемат тези функции. Та е важно (както споменах и по-горе) да има една резервна лидерска скамейка, на която има хора, можещи да поемат отговорност.

А може просто да няма формализиран lead, и ролята да се мести, или просто да се случва сама. Това също е работещ вариант при правилните хора, и е просто една голяма “резервна скамейка”, от която някой става, когато е нужно.

Такива примери имам много, от всякакви организации, но най-лесния за илюстриране и един от от любимите ми (даже се оказа, че съм го ползвал в друга моя лекция :) ). Това се случва в петък вечер преди OpenFest 2018. Аз съм се прибрал да си гледам жената и детето (тогава само едно), и нещо се счупва с интернета и сървъра. И няколко човека, които всъщност не са настройвали тая част, щото са били заети с други неща сядат и го оправят (с малко обаждане по телефона да ме питат нещо).

Да си призная, тези хора ми бяха от любимите екипи :)

Почистването на екип е от нещата, с които съм се занимавал най-малко. Старая се основно да не се налага, понеже това губи време и изтормозва всички.

Виждал съм най-различни случаи на проблемни хора. За тях има различни решения, като тръгнем от корекция на конфликти, разделение на отговорности (ако някакви хора не могат да се траят, но трябва да работят в близки екипи), до директно раздяла с някого. Важното при всички такива решения е да са ясни защо се случват и да се случват.

Това по принцип е една от най-тежките задачи, и във фирмите даже си има хора за тая работа, да играят лошия, когато ни дойде желание да избягаме от отговорност…

А трябва ли да се занимваме с това? Да сме в екип, да го поддържаме, да работим заедно?

За някои хора не. Има достатъчно неща, за които може да си one-man show и да сработят, и познавам хора, които правят точно това – гледат да са единствените, които се занимават с дадено нещо и да си го организират така, че да не им е проблем.

За мен си заслужава и винаги си е заслужавало. Правил съм неща сравнително сам, и съм наясно какво мога да постигна. Постигал съм повече в различни екипи, и определено си е заслужавало. Препоръчвам на всички :) В някои отношения е по-трудно от работата с компютри, в някои е по-лесно, но съм се убедил, че е важно.

И ако се огледаме около себе си, огромна част от света, в който живеем се е случил и развил заради групи от хора с определена цел.

Оставям един slide с малко допълнителни ресурси, има ли някакви въпроси?

Голяма лудница ми е, та все не стигам да напиша тия няколко реда (и щяха да останат за равносметката), но държа да кажа:

OpenFest 2023 се случи без мен.

Правих някакви дребни неща, но не съм бил в организацията, нещата се случиха някакси, аз бях там само за да си тествам setup-а за FOSDEM. Да съм честен, най-трудното ми беше да не давам нареждания, щото навикът е страшна работа…

Та, по някое време догодина като направим събрание на фондацията да я предам, ще съм приключил с тая си част от живота. Екип се намира да движи нещата, та съм спокоен :)

п.с. по предишната тема за junior администраторите ще пиша отделно.

Мислех да пиша recap на OpenFest 2022, но ми е твърде уморено. Направихме един работещ фест след няколко години online и малки събития, получи се с нормалното количество проблеми, съвсем накратко :)

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

Така като си погледна архивите, като изключим 2003, 2012 и 2020, съм участвал във всички останали, като в последните 10 години – като един от основните координатори. Ако продължа да се занимавам, вероятно ще тръгна да правя побъркани неща като 10gbps wireless и т.н., а си мисля, че моите идеи за какво е хубаво да се прави/случва може вече да не са съвсем правилни :)

Нямам особено притеснение за самия фест – има сериозен екип, който може да се справя с организирането, имаме изградена система за почти всичко, така че съм съвсем спокоен, че всичко може да се случи и без мен.

Все пак, крайно време е да ида един път на OpenFest като обикновен посетител, не ми се е случвало от 2003 :)

Това е подготвения текст за лекцията, доста се разминава с това, което
говорих, но би трябвало поне смисъла да е същия :)

Ще ви разкажа за една от основните ми задачи в последните 5 години.

Преди да започна в StorPool, monitoring-ът представляваше нещо, което
периодично се изпълняваше на всяка машина и пращаше mail, който не беше съвсем
лесен за разбиране – нямаше начин да се види едно обща картина. За да мога да
се ориентирам, сглобих нещо, което да ми помогне да виждам какво се случва.
Лекцията разказва за крайния резултат.

Ще го повторя няколко пъти, но няма нищо особено специално, магическо или ново
в цялата лекция. Правя това от няколко години, и честно казано, не мислех, че
има смисъл от подобна лекция, понеже не показва нещо ново – не съм направил откритие
или нещо невероятно.

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

Та, как пред ръководството да оправдаем хабенето на ресурси за подобна система
и да обясним, че правим нещо смислено, а не се занимаваме с глупости?

Ако нещо не се следи, не работи. Това е от типа “очевидни истини”, и е малка
вариация на максима от нашия development екип, които казват “ако нещо не е
тествано, значи не работи”. Това го доказваме всеки път, когато се напише нов
вид проверка, и тя изведнъж открие проблем в прилична част от всички
съществуващи deployment-и. (наскоро написахме една, която светна само на 4
места, и известно време проверявахме дали няма някаква грешка в нея)

Monitoring-ът като цяло е от основните инструменти за постигане на situational
awareness.

На кратко, situational awareness е “да знаеш какво се случва”. Това е различно
от стандартното “предполагам, че знам какво се случва”, което много хора правят
и което най-хубаво се вижда в “рестартирай, и ще се оправи”. Ако не знаеш къде
е проблема и действаш на сляпо, дори за малко да изчезне, това на практика нищо
не значи.

Та е много важно да сме наясно какво се случва. И по време на нормална работа,
и докато правим проблеми, т.е. промени – важно е да имаме идея какво става.
Много е полезно да гледаме логовете докато правим промени, но monitoring-а може
да ни даде една много по-пълна и ясна картина.

Да правиш нещо и изведнъж да ти светне alert е супер полезно.

(По темата за situational awareness и колко е важно да знаеш какво се случва и
какви са последствията от действията ти мога да направя отделна лекция…

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

Да започнем с малко базови неща, които трябва да обясня, като говоря за monitoring.

Едното от нещата, които се събират и се използват за наблюдаване на системи са
т.нар. метрики. Това са данни за миналото състояние на системата – може да си
ги представите най-лесно като нещата, които се визуализират с grafana.
Най-честата им употреба е и точно такава, да се разглеждат и да се изследва
проблем, който се е случил в миналото (или пък да се генерират красиви картинки
колко хубаво ви работи системата, което маркетинга много обича).

Друго нещо, за което са много полезни (понякога заедно с малко статистически
софтуер) е да се изследват промени в поведението или как определена промяна е
повлияла. Това до колкото знам му казват да сте “data driven”, т.е. като
правите нещо, да гледате дали данните казват, че сте постигнали това, което
искате.

Метриките, които аз събирам са веднъж в секунда, за много различни компоненти
на системата – дискове, процесори, наши процеси, мрежови интерфейси. В момента
са няколко-стотин хиляди точки в секунда, и тук съм показал една примерна –
показва данните за една секунда за един процесор на една машина, заедно с малко
тагове (че например процесорът не се използва от storage системата, та за това
там пише “nosp”) и с timestamp.

Метриките са нещо, което не искаме да се изгуби по пътя или по някаква друга
причина, защото иначе може да се окаже, че не можем да разберем какво се е
случило в даден момент в системата. В някакъв вид те са като “логове”.

Метриките се събират веднъж в секунда, защото всичко друго не е достатъчно ясно
и може да изкриви информацията. Най-простия пример, който имам е как събитие,
което се случва веднъж в минута не може да бъде забелязано като отделно такова
на нищо, което не събира метрики поне веднъж на 10 секунди.

Също така, събития, които траят по секунда-две може да имат сериозно отражение
в/у потребителското усещане за работа на системата, което пак да трябва да е
нещо, което да трябва да се изследва. В 1-секундните метрики събитието може да
е се е “размазало” достатъчно, че да не е видимо и да е в границите на
статистическата грешка.

Имам любим пример, с cron, който работеше на една секунда и питаше един RAID
контролер “работи ли ти батерията?”. Това караше контролера да блокира всички
операции, докато провери и отговори, и на минутните графики имаше повишение на
латентността на операциите (примерно) от 200 на 270 микросекунди, и никой не
можеше да си обясни защо. На секундните си личеше, точно на началото на всяка
минута, един голям пик, който много бързо ни обясни какво става.

(отказвам да коментирам защо проверката на статуса на батерията или каквото и
да е, което питаме контролера отвисява нещата, най-вече защото не знам къде
живеят авторите на firmware)

Та това се налага да го обяснявам от време на време, и да се дразня на системи
като Prometheus, където практически по-добра от 3-секундна резолюция не може да
се постигне.

Също така, не знам дали мога да обясня колко е готино да пускате тестове, да
сте оставили една grafana да refresh-ва веднъж в секунда и почти в реално време
да може да виждате и да показвате на хората как влияят (или не) разлини
действия на системата, от типа на “тук заклахме половината мрежа и почти не се
усети”.

Другото нещо, което се следи е текущото състояние на системата. Това е нещото,
от което се смята статуса на системата в nagios, icinga и други, и от което се
казва “тук това не работи”. Системите, които получават тази информация решават
какви проблеми има, кого и дали да известят и всякакви такива неща.

Статусът е нещо по-общо, и май нямам пример, който мога да събера на един слайд
и да може да се разбере нещо. Много често той носи допълнителна информация,
от която може да дойде нещо друго, например “мрежовата карта е с еди-коя-си
версия на firmware”, от което да решим, че там има известен проблем и да
показваме алармата по различен начин.

Метриките са доста по-ясни като формат, вид и употреба – имат измерение във
времето и ясни, числови параметри. Останалите данни рядко са толкова прости и
през повечето време съдържат много повече и различна информация, която не
винаги може да се представи по този начин.

Един пример, който мога да дам и който ми отне някакво време за писане беше
нещо, което разпознава дали дадени интерфейси са свързани на правилните места.
За целта събирах LLDP от всички сървъри, и после проверявах дали всички са
свързани по същия начин към същите switch-ове. Този тип информация сигурно може
да се направи във вид на метрики, но единствено ще стане по-труден за употреба,
вместо да има някаква полза.

А какъв е проблема с цялата тази работа, не е ли отдавна решен, може да се питате…

Като за начало, ако не се постараете, данните ви няма да стигнат до вас. Без
буфериране в изпращащата страна, без използване на резервни пътища и други
такива, ще губите достатъчна част от изпращаните си данни, че да имате дупки в
покритието и неяснота какво се случва/се е случило.

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

Дори като bandwidth не са малко, и хубавото на това, че имаме контрол в/у двете
страни, e че можем да си ги компресираме, и да смъкнем около 5 пъти трафика.
За това ни помага и че изпращаните данни са текстови, CSV или JSON – и двете
доста се поддават на компресия.

Няма някой друг service при нас, който да ползва сравнимо количество internet
bandwidth, дори някакви mirror-и :)

Идващите данни трябва да се съхраняват за някакво време. Добре, че фирмата
се занимава със storage, та ми е по-лесно да си поискам хардуер за целта…

За да можем все пак да съберем всичко, пазим само 2 дни секундни данни и 1
година минутни. InfluxDB се справя прилично добре да ги компресира – мисля, че
в момента пазим общо около двайсетина TB данни само за метрики. За
monitoring данните за debug цели държим пращаните от последните 10 часа, но
това като цяло е лесно разширимо, ако реша да му дам още място, за момента
се събират в около 1.6TiB.
(Това е и една от малкото ми употреби на btrfs, защото изглежда като
единствената достъпна файлова система с компресия… )

Ако погледнем още един път числата обаче, тук няма нищо толкова голямо, че да
не е постижимо в почти “домашни” условия. Гигабит интернет има откъде да си
намерите, терабайтите storage дори на ssd/nvme вече не са толкова
скъпи, и скорошните сървърни процесори на AMD/Intel като цяло могат да вършат
спокойно тая работа. Та това е към обясненията “всъщност, всеки може да си го
направи” :)

Системите, които наблюдаваме са дистрибутирани, shared-nothing, съответно
сравнително сложни и проверката дали нещо е проблем често включва “сметка” от
няколко парчета данни. Като сравнително прост пример за някаква базова проверка
– ако липсва даден диск, е проблем, но само ако не сме казали изрично да бъде
изваден (флаг при диска) или ако се използва (т.е. присъства в едни определени
списъци). Подобни неща в нормална monitoring система са сложни за описване и
биха изисквали език за целта.

Имаме и случаи, в които трябва да се прави някаква проверка на база няколко
различни системи, например такива, които регулярно си изпращат данни – дали
това, което едната страна очаква, го има от другата. Понякога отсрещните страни
може да са няколко :)

Статусът се изпраща веднъж в минута, и е добре да може да се обработи
достатъчно бързо, че да не се натрупва опашка от статуси на същата система.
Това значи, че monitoring-ът някакси трябва да успява да сдъвче данните
достатъчно бързо и да даде резултат, който да бъде гледан от хора.

Това има значение и за колко бързо успяваме да реагираме на проблеми, защото
все пак да се реагира трябва трябва да има на какво :)

И имаме нужда тази система да е една и централизирана, за можем да следим
стотиците системи на едно място. Да гледаш 100 различни места е много трудно и
на практика загубена кауза. Да не говорим колко трудно се оправдава да се сложи
по една система при всеки deployment само за тази цел.

Това има и други предимства, че ако наблюдаваните системи просто изпращат данни
и ние централно ги дъвчем, промяна в логиката и добавяне на нов вид проверка
става много по-лесно. Дори в модерните времена, в които deployment-а на хиляда
машини може да е сравнително бърз, пак трудно може да се сравнява с един локален
update.

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

От какво е сглобена текущата ни система?

За база на системата използвам icinga2. В нея се наливат конфигурации, статуси
и тя решава какви аларми да прати и поддържа статус какво е състоянието в
момента.

Беше upgrade-ната от icinga1, която на около 40% от текущото натоварване умря и
се наложи спешна миграция.

InfluxDB, по времето, в което започвах да пиша системата беше най-свястната от
всичките съществуващи time series бази.

Като изключим доста осакатения език за заявки (който се прави на SQL, но е
много далеч и е пълен със странни ограничения), и че не трябва да се приема за
истинска база (много глезотии на mysql/pgsql ги няма), InfluxDB се справя добре
в последните си версии и не може да бъде crash-ната с някоя заявка от
документацията. Основното нещо, което ми се наложи да правя беше да прескоча
вътрешния механизъм за агрегиране на данни и да си напиша мой (който не помня
дали release-нахме), който да може да върши същото нещо паралелно и с още малко
логика, която ми трябваше.

От някакво време има и версия 2, която обаче е променила достатъчно неща, че да
не мога още да планирам миграция до нея.

Както обясних, проверките по принцип са не-елементарни (трудно ми е да кажа
сложни) и логиката за тях е изнесена извън icinga.

В момента има около 10k реда код, понеже се добавиха всякакви глезотии и
интересни функционалности (човек като има много данни, все им намира
приложение), но началната версия за базови неща беше около 600 реда код, с
всичко базово. Не мисля, че отне повече от няколко дни да се сглоби и да се
види, че може да върши работа.

Ако ползвате стандартен метод за активни проверки (нещо да се свързва до
отсрещната страна, да задава въпрос и от това да дава резултат), никога няма да
стигнете хиляди в секунда без сериозно клъстериране и ползване много повече
ресурси.

Дори и да не ползвате стандартните методи, пак по-старите версии на icinga не
се справят с толкова натоварване. При нас преди няколко години надминахме
лимита на icinga1 и изборът беше м/у миграция или клъстериране. Миграцията се
оказа по-лесна (и даде някакви нови хубави функционалност, да не говорим, че се
ползваше вече софтуер от тоя век).

Основният проблем е архитектурен, старата icinga е един процес, който прави
всичко и се бави на всякакви неща, като комуникация с други процеси,
писане/четене от диска, и колкото и бърза да ни е системата, просто не може да
навакса при около 20-30к съществуващи услуги и няколко-стотин статуса в
секунда. А като му дадеш да reload-не конфигурацията, и съвсем клякаше.

Изобщо, технически това един бивш колега го описваше като “десет литра лайна
в пет литра кофа”.

Новата например reload-ва в отделен процес, който не пречи на главния.

Признавам си, не обичам Prometheus. Работи само на pull, т.е. трябва да може да
се свързва до всичките си крайни станции, и като го пуснахме за вътрешни цели с
около 100-200 машини, почна да му става сравнително тежко при проверка на 3
секунди. Също така изобщо няма идеята да се справя с проблеми на internet-а,
като просто интерполира какво се е случило в периода, в който не е имал
свързаност.

Върши работа за някакви неща, но определен е далеч от нашия случай. Според мен
е и далеч от реалността и единствената причина да се ползва толкова е многото
натрупани готови неща под формата на grafana dashboard-и и exporter-и.

Компонентите са в общи лини ясни:

Агентите събират информация и се стараят да ни я пратят;

Получателите я взимат, анализират, записват и т.н.;

Анализаторите дъвчат събраната информация и на база на нея добавят още
проверки.

Тук не измислих как да го покажа, но това е един thread, който събира данни (от
няколко такива), и има един който изпраща данните и се старае да стигнат. Пак е
сравнително малко код и може да бъде сглобен почти от всеки.

За данни, за които повече бързаме да получим и не буферираме, има друг
интересен трик – да имате няколко входни точки (при нас освен нашия си интернет
имаме един “домашен”, който да работи дори да стане някакво бедствие с
останалия), съответно агентът се опитва да се свърже едновременно с няколко
места и което първо отговори, получава данните.

Понеже това е писано на perl по исторически причини, беше малко странно да се
направи (понеже select/poll на perl, non-blocking връзки и подобни неща не са
съвсем стандартни), но сега мога да го похваля, че работи много добре и се
справя вкл. и с IPv6 свързаност.

И всичкия код, който получава/прави анализи си е тип ETL
(extract-transform-load). Взима едни данни, дъвче, качва обратно.

В нашия случай това, което връща са състояния и конфигурации (ще го покажа
по-долу).

И един елементарен пример, почти директно от кода – обикаля данните за набор от
машини, проверява дали в тях има нещо определено (kernel, за който нямаме
качена поддръжка) и го отбелязва.

Има и по-интересни такива неща (анализи на латентности от метриките, например),
но нямаше да са добър пример за тук :)

“Липсата на сигнал е сигнал” – можем да знаем, че нещо цялостно или част от
него не ни говори, понеже имаме контрол в/у агентите и кода им, и знаем
кога/как трябва да се държат.

Някой би казал, че това се постига по-добре с активна проверка (“тия хора
пингват ли се?”), но това се оказва много сложно да се прави надеждно, през
интернета и хилядите firewall-и по пътя. Също така, не може да се очаква
интернета на всички да работи добре през цялото време (заради което и всичките
агенти са направени да се борят с това).

Както казах по-рано, Интернета не работи :)

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

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

Системата се грижи всичко останало да се случва съвсем само.

Това, което според мен е най-важното за тази и подобни системи – няма нищо
особено сложно в тях, и всеки, който се нуждае от нещо такова може да си го
сглоби. Първоначалната ми версия е била около 600 реда код, и дори в момента в
10-те хиляди реда човек може да се ориентира сравнително лесно и да добави
нещо, ако му се наложи.

Като пример, дори python програмистите при нас, които считат, че php-то трябва
да се забрани със закон, са успявали да си добавят функционалност там
сравнително лесно и със съвсем малко корекции по стила от моя страна.

Самото php се оказва много удобно за подобни цели, основно защото успява да се
справи и с объркани данни (което се случва при разни ситуации) и не убива
всичко, а си се оплаква и свършва повечето работа. Разбира се, това не е
единствения подходящ език, аз лично писах на него, защото ми беше лесен – но
ако искате да сглобите нещо, в наши дни може да го направите почти на каквото и
си искате и да работи. Python и js са някакви основни кандидати (като езици,
дето хората знаят по принцип), само не препоръчвам shell и C :)

Така че, ако ви трябва нещо такова – с по-сложна логика, да издържа повече
натоварване, да прави неща, дето ги няма в други системи – не е особено сложно
да го сглобите и да тръгне, нещо минимално се сглабя за няколко дни, а се
изплаща супер бързо :)

Monitoring системата се налага да се следи, разбира се. Всичкият софтуер се
чупи, този, който аз съм правил – още повече. По случая други колеги направиха
нещо, което да следи всичките ни вътрешни физически и виртуални машини, и това
между другото следи и големия monitoring :)

Изглежда по коренно различен начин – използва Prometheus, Alertmanager и за
база VictoriaMetrics, което в общи линии значи, че двете системи рядко имат
същите видове проблеми. Също така и допълнителния опит с Prometheus ми показа,
че определено е не е бил верния избор за другата система :)

Може би най-големият проблем, който съм имал е да обясня какво значи текста на
дадена аларма на други колеги. Тук например съм казал “има малък проблем (за
това е WARNING), в услугата bridge, има един счупен, нула игнорирани (по разни
причини) и 2 общо, и този на машина 4 е down” – и това поне трима различни
човека са ми казвали, че не се разбира. Последното ми решение на проблема е да
карам да ми дадат как очакват да изглежда и да го пренаписвам. От една страна,
съобщенията станаха по-дълги, от друга – не само аз ги разбирам :)

Няколко пъти се е случвало системата да изпрати notification на много хора по
различни причини – или грешка в някоя аларма, или просто има проблем на много
места. Като цяло първото може доста да стресне хората, съответно вече (със
съвсем малко принуда) има няколко staging среди, които получават всички
production данни и в които може да се види какво ще светне, преди да е стигнало
до хора, които трябва да му обръщат внимание.

Изобщо, ако човек може да си го позволи, най-доброто тестване е с production
данните.

Основна задача за всяка такава система трябва да е да се намалят алармите до
минимум. Би трябвало фалшивите да са минимален брой (ако може нула), а едно
събитие да генерира малко и информативни такива. Също така, трябва да има лесен
механизъм за “умълчаване” на някаква част от алармите, когато нещо е очаквано.

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

Решението тук е да се вземат алармите за един ден, и да се види кое от тях е
безсмислено и кое може да се махне за сметка на нещо друго, след което мноооого
внимателно да се провери, че това няма да скрие истински проблем, вероятно с
гледане на всички останали задействания на неприемливото съобщение. Което е
бавна, неблагодарна и тежка работа :)

Не исках да слагам този slide в началото, че сигурно нямаше да остане никой да
слуша лекцията. Оставям го да говори сам за себе си:)

Огромна лудница ми е, та явно съвсем забравям да пиша.

Две неща, свързани с OpenFest 2022 – може да си запазите тениски, и да гласувате за submit-натите лекции и workshop-и за програмата.

Добрутро.

Ще има пак OpenFest, 20-то издание, пак в София Тех Парк.
Изданието е юбилейно (поне в десетичната бройна система), та събираме желаещи да говорят, да правят работилници (т.е. workshop-и), както и да помагат. Както обикновено, записването е на cfp.openfest.org, срокът за лекции и т.н. е до 1.09.2022.

Чакаме с нетърпение :)

Записите са готови (от известно време), в архива и в youtube.

Ще се случва OpenFest 2021.

Ще е на открито, в “Маймунарника” в Борисовата градина, 14-15 август (стига да не се случи ОЩЕ нещо форсмажорно).

По случая – търсим лектори (особено за workshop-и) и както обикновено, набираме доброволци.

За пръв път организираме по този начин нещата, и въпреки че има да се решат всичките стандартни проблеми на ново място, събитието отсега се очертава да бъде забавно, и за присъствие, и за организиране :)

(каня се от известно време да напиша нещо за наемането на хора, но все не ми остава време. За това – събирателен post с някакви случили се неща)

Успях да изкарам двустранна пневмония. Не е ясно как съм я хванал – прояви се няколко дни след втората доза ваксиниране, COVID тестовете ми излизаха отрицателни, и освен да съм пипнал нещо на някоя опашка, не ми хрумва друг вариант. Изписаха ми два мощни антибиотика, пих ги две седмици и сега още се оправям, малко по малко.
(добре, че семейството преди това беше заминало в Бургас, и не трябваше да ме гледат и мен заедно с децата)

На рентгеновите снимки вече не се вижда проблем, на слушалка последния път се чуваше нещо (и след още няколко седмици пак ще ида да ме преслушат), а нивата ми на сатурация стоят на 97 (проверих специално апарата дали е добре, и при Елена показваше 99, та проблемът си е в мен явно), та ще се работи бавничко по възстановяването.

In other news, има колебание какво да се прави с OpenFest. Има една анкета на bit.ly/openairopenfest за дали да направим нещо на открито през лятото, има въпроса дали да се опитаме и нещо на закрито есента, но тотално го няма въпроса дали да направим чисто online събитие – по всичко, което чувам/усещам, на всички им е омръзнало. Най-хубавия цитат по темата ми е от преди няколко дни от един семинар на RIPE, в който някой каза “писнало ми е от zoom meeting-и, в които се оплакваме от zoom meeting-ите”.

Ако не сте попълнили анкетата и ви е интересен феста, напишете нещо. От наша страна ще има опит да съберем екип (понеже всички изглеждат адски уморени и не знам дали искам да им го причинявам), и се надявам до няколко седмици да има някаква яснота.

Също така, не е задължително да правим каквото и да е. Може просто да оставим хората да се събират по кръчмите/парковете, да се видят и малко по малко да работят по въпроса да не им трябват психотерапевти…

Съвсем накратко.

Ще има online OpenFest 2020. Търсят се доброволци и лектори.

Най-вероятно и така ще е забавно, та – включвайте се:)

В последните няколко годинии (2017, 2018) сглабям по някаква online игра за щанда на StorPool на OpenFest. Тази година пак сглобих нещо такова, и понеже изисква някаква сървърна част, просто ще му напиша описание, а който иска, може да го setup-не някъде, всичките му неща могат да се свалят от quiz.storpool.com/of2019.tgz.

Играта изглеждаше по следния начин: в началото човек се логва на един сървър, и в motd-то го посреща описание от “предишния човек”, който е hack-вал машината:


yo

i kept working on this, but what i've seen that there's
a strange firewall, and we need to get to port 3xxx. there's
some readme in a weird encoding, no idea how to read that.

gl


Информацията в този текст в общи линии е “нещо слуша на порт 3xxx, има странен firewall, има документация във формат, който не мога да прочета, и тия хора от криптография не разбират”.

В директорията освен този файл (“y00dud3”) има още два – kdctl.dump и manual.EBCDIC-INT. kdctl.dump е strace на /opt/kd/linux-x86_64/devel/bin/kdctl, който може да се види как прави connect() до localhost на порт 3xxx (където “xxx” е номерчето на user-а, имаше отделен порт за всеки участник). Ако човек се опиташе да пусне kdctl, му даваше permission denied (и такова нещо няма, сложих просто permission-и 000 на една от директориите по пътя), така че човек трябва сам да се прави на клиента.

manual.EBCDIC-INT представлява малко документация, обърната в EBCDIC, която човек може да си конвертира обратно с iconv (или както се оказа, с dd). Вътре има описание на системата, с която трябва да се говори, и малко development информация за протокола, като част от информацията е криптирана:


KroberDyne access terminal v2.1.18-fcdb1fa
==========================================

!!! This document is property of KroberDyne corporation. A license is
!!! granted to the purchaser of this system for 1 (one) copy. All
!!! unauthorized copies must be destroyed.

All rights reserved, KroberDyne corporation(tm)


(“Kroberdyne” е някаква комбинация от cyberdyne (корпорацията във филмите за Terminator) и крокодил)

“Криптирането” е ROT13 (което мисля, че дори се вижда) и вътре има следното:


WAIT - the access terminal is by default delay-limited to not
overflow slow serial links. This parameter controls delay
in ms. Usage restricted to technicians.


DBUG - dumps a specific table in software.
USAGE RESTRITED TO KROBERDYNE SECURITY STAFF ONLY.


И така, имаме протокол, с който да си говорим с един демон локално, и да се опитаме да вземем някакъв auth code. Като направим telnet localhost 3xxx, получаваме:


$ telnet localhost 3001
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
200-KroberDyne terminal VT18. Unathorized access prohibited.
200 Welcome 001
>


Тук има няколко неща, не всички са задължителни:
– LANG en, и след това HELP ще ви даде един списък от команди (иначе казва, че няма такъв файл);
– WAIT 0 ще махне забавянето при печатане (което е random wait м/у всеки 2 букви и изглежда бая странно);
– AUTH ще ви каже 3 codebook-а, от които да извадите парола;
– DBUG codebook ще ви извади всичките пароли от определения codebook, и
– PASS парола (която се среща и в 3-те codebook-а) ще ви даде код да си получите тениската.

(това с DBUG може да ви се струва невероятно, но е по съвсем истински случай, използван от първия worm в Internet)

Няколко неща може би не бяха ясни – например имаше 30-минутен time limit за всички пробващи се и после им lock-ваше account-а (което май не сработи точно както трябваше), и може би не беше ясно до какво точно трябва да се стигне. Хората, решили задачата са малко, доколкото знам, та явно догодина ще трябва повече подсказки. Портовете бяха филтрирани така, че всеки да може да се връзва само на собствения си, и всъщност имах и идеята да изисквам определен range за source port, но не намерих за краткото време, което имах лесен начин човек да си намества source port-а от telnet, и реших да го прескоча.

Иначе, интерактивен сървър с команди се оказа тривиален за правене, с малко python и един rlinetd да се занимава с TCP-то отпред, може да видите колко е тривиален кода вътре.

Та, ако някой се е съмнявал, да кажа – ще има OpenFest 2019. Тази година имаме някаква насоченост към бъдещето, и едната посока е човешкото бъдеще, т.е. ученици и други деца, та от там и голямото “Tomorrow” в страницата. Очаквайте по-ясно описание на самия сайт (аз малко недоспивам тия дни).

Както винаги си търсим доброволци и лектори.

(английската версия е в блога на StorPool)

В последните няколко години StorPool се появяват на OpenFest. За да направим щанда по-забавен, измисляме някоя игра. Миналата година задачата изглеждаше измамно проста, но доста затрудни хората, та тази година реших да опитам с нещо по-лесно.

“Fix the problems” задачата е базирана на много някакви стандартни случки от админския живот, т.е. на нещо, което би трябвало да ви се е случвало. Представете си обаждане от приятел (което може да е в 8 сутринта), в което ви казват “live сме с тая система, ама даже не тръгва, ПОМОЩ”. Та, логвате се и откривате ужасяваща кочина, сглобена от неща, правени от различни хора на различни езици, не-тествана и пълна с малки и големи проблеми, и трябва да проработи.

(или може би само на мен се случва, знам ли…)

Може да се пробвате, като свалите задачката с примерни данни от quiz.storpool.com/of2018.tgz и се пробвате. Отговорът започва с “8”.

За приключилите и нетърпеливите, ето описание:
Задачата се състои от следните файлове: a.c, a.php, a.pl, a.py, run.sh (който си мислех да кръстя “a.sh”) и един Makefile. “run.sh” свързва всички останали заедно, да сметне някакъв резултат от данните в “data/” директорията.

Цялото нещо си има история – имало 4 различни програмиста – C файлът бил написан от човек, който говори английски, PHP-то от финландец, Perl-а от унгарец, Python-а от арабин, и shell script-а от българин. Всички са имали лошо мнение за останалите и са оставили коментари в кода по адрес на останалите.

Счупванията са сравнително тривиални, понеже time limit-а за цялата задача беше 30 минути и имаше разни заблуждаващи моменти. Започвам от свързващия файл и после по pipe-а:

run.sh навързва всичките останали. Основната грешка е, че липсва -0 параметъра на xargs (което се забелязва доста лесно, понеже find използва -print0). Друга гадост е, че файлът е с DOS-овски нови редове и не може да бъде стартиран нормално, или трябва да се подменят, или да си копирате отвътре pipe и да го пуснете на ръка.

В коментарите може да се види как авторът нарича останалите “идиоти” (което съм сигурен, че всички са виждали в някакъв вид), и списъкът му за пазаруване. Последното може да се вижда странно и невероятно, но е нещо, което съм виждал в production код – случва се, като трябва веднага да се запише нещо и човекът го мързи да отвори нов прозорец в редактора или да намери малко хартия.
(някакъв спомен ми се мотае, че случая, който бях виждал беше поръчка за KFC…)

a.php добавя 1 към всички числа, и за да дразни останалите разработчици, добавя и допълнителни интервал. Очевидната грешка е че вместо STDIN е написано STDON, което бързо се оправя.

В коментарите се вижда как програмистът не е щастлив с останалите от екипа и водката му е почти свършила. Не съм виждал лично подобен коментар, но съм чувал от достоверни източници за подобни случаи. Колкото до смисъла от подобен код, има ужасно много такива дребни неща в много проекти, които никога не е трябвало да съществуват, но все пак са там.

a.pl просто премахва всички интервали, т.е. създава едно голямо число от всичките числа на реда. Грешката е, че се използва $__ вместо $_ – лесна за забелязване правописна грешка.

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

a.py взима всички числа и връща остатъкът им при деление на 2^63 (което е hard-code-нато като 9223372036854775808). Грешката тук е, че цикълът започва с while False:, което няма никакъв смисъл, и смяната му на while True: решава проблема. Самият код е малко по-гаден от останалите, понеже има променливи с имена на арабски, които се изписват от дясно на ляво и могат да объркат терминала, но в крайна сметка тези части не трябва да се пипат.

Оплакването на края е, че ако не си бил взел трета жена, нямало да му се налага да работи с тези хора…

И накрая, a.c прави странни изчисления и вади остатъка от деление на 2^10 на резултата в шестнайсетичен вид (за да е достатъчно кратко, че да върши работа за отговор). Грешката в кода е, че целочисленият тип в началото е грешен и трябва да се работи с long long (което се вижда в останалия код). Това е и причината в Makefile да има -Werror -Wall, за да се забележи лесно проблема.

А коментарите във файла са премахнати заради “PARA-22”, което не би трябвало да има нужда от дообясняване.

Цялото нещо може да изглежда много невероятно, особено колко е чувствително към числата и размера им. Мога да се оправдая с това, че е игра и че основно трябва да е забавно (и че ме мързи), но за съжаление подобни неща съм виждал достатъчно често или са ми разказвали за тях. Поне се надявам, че участниците са се забавлявали:)

Записите са готови, може да се свалят от видеоархива или да се гледат в тубата.

Накратко, vote.openfest.org – може да гласувате за лекциите, които искате да видите на OpenFest 2018.

Това иначе никога няма да го кача, та ето го като dump от оригналния документ, ако някой му се занимава да го преведе до смислен html да каже да му дам link към оригинала.

OpenFest 2017 network write-up

И изкарахме записите от OpenFest 2017. Може да се намерят в архива и в youtube.

Нещата се забавиха най-вече заради намазани записи и нуждата да възстановяваме от резервните (накратко, да имаш 3 backup-а е полезно).

(по-подробно за феста – като се наспя)

За OpenFest 2017 за щанда на StorPool бях написал една задача, та който я реши, да получи тениска. Задачата звучи измамно просто и аз също не съм се усетил, че не е лесно решима за 10 минути.

Задачата е следната – имате директория с някакво количество файлове, да видите кои от тях са MD5 и кои – SHA1 колизии, и да дадете първите букви от имената им (4 файла за md5 и 4 за sha1). Моето решение беше във временна директория да се направят файлове с имена MD5 (и после – SHA1) сумите, в които да се напишат имената и SHA256 сумите на файловете с тая MD5 сума, и после с един sort на всеки файл лесно се вижда в кой има различни файлове (трябва да са еднакви по принцип). Ако е просто да се види коя е md5 сумата, може да се броят уникалните sha256 суми във всички файлове, да се види къде са колизиите.

Интересно ще ми е наистина ли е толкова трудна задачата (доколкото знам, за два дни само един човек я е решил за 10 минути).

Също така ми е интересно дали някой не е решил да пита google какви са checksum-ите на демонстрационните sha1/md5 колизии и да види дали аз не съм си събрал файловете по тоя начин…

Кодът, който генерира задачата е качен на https://vasil.ludost.net/progs/storpool-of-task.tgz. Вътре има gen.sh, който трябва да се пипне малко къде да прави файловете и който при пускане създава малко файлове и ви дава отговора. Не съм сложил другите неща (това, което се прави на login shell и нещото, което праща отговорите по slack на проверяващия), но те не са толкова интересни.

И малко OpenFest-овски неща.

Имаме списък подадени лекции, от които да се направи програма. На програмния комитет му е полезно мнението на хората, та може да гласувате на vote.openfest.org какво би ви било интересно.

Събираме доброволци за всякаквите екипи. Може да дадете заявка директно тук, все ще ви намерим какво да вършите. Аз лично издирвам някакви хора да настроят малко IP телефони, че все не успявам да стигна до там…

Ще имаме отделен call for hardware, за разни неща, дето не ни достигат (за момента май основно по-големи телевизори и трябва да видя какво стана с радиостанциите).

(най-важния call – да дойдете и да се забавлявате мисля, че няма нужда да се обявява)

Като новина за понеделник сутрин – може да подавате заявки за лекции и workshop-и за OpenFest 2017. Имаме огромно пространство за workshop-и, та ако искате да показвате нещо от типа на “запояване на челна стойка”, ще се радваме да го видим.