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

Преди известно време 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 с малко допълнителни ресурси, има ли някакви въпроси?

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

Докато четях “The view from the cheap seats” на Нийл Геймън, ми хрумна да направя тая лекция. Може да гледате слайдовете, докато я четете, но да знаете, че няма нито една картинка. Опитал съм се да следвам донякъде каквото говорих на самата презентация.
(добавих нещо интересно към генератора ми на презентациите, epub версия, която може да се гледа на някакъв reader вместо бележки)

ХУДЛ: една полезна дрога
———————–

Добрутро, добри хора.

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

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

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

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

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

Има неща, за които няма да говоря. Ще пропусна всичкият non-fiction (който в момента може би е половината от това, което чета) – техническа, историческа и всякаква научна литература – там има също шедьоври и полезни неща, но те изискват по-скоро цикъл лекции (например “на какво може да ни научи историческата литература”, “технически книги, написани добре” или “основен курс по политика и защо ни е”). Иска ми се да говоря и за комиксите, но те заслужават съвсем отделна лекция, и също така ще пропусна книгите-игри, понеже имам твърде малък досег с тях.

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

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

По-лек вариант на това е просто да се озовете в друг свят, който да ви помогне да си промените представите. Има различни начини:

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

Друг вариант са сериалите (всъщност аз даже гледам сериали). Те имат предимството, че са по-дълги и могат да съберат една книга както трябва, да изградят историята и героите както трябва, и даже могат в общи линии да предадат една книга – примерът е как Game of thrones се получава (на филм нямаше как да стане), и поне според мен Властелинът на пръстените щеше да е много по-добре на сериал, отколкото на 10 часа филми.
Проблем е пак, че няма достатъчно материал – освен, че няма порно сериали, по принцип производството им е бавно и тежко. Въобще, всичко кинематографично иска много по-голям ресурс.
Също така, и двете не оставят време за мислене. И филмите, и сериалите се движат със собствено темпо, което не ви дава възможност да спрете и да помислите, да предъвчете информацията. Също така трудно може да се избърза – например наскоро гледах сериал, на който първия сезон беше зле, втория ставаше и третия беше невероятен, но нямаше как да мина бързо през първия, понеже не е само пълнеж, но и setup на историята, който си е важен. Може би просто няма решение на тоя проблем…
Пак вдигат шум, и пак са ужасно клиширани. Всеки път, като гледаш нещо в общи линии е ясно какво ще се случи, просто защото пътеките са утъпкани и никой не смее да излезе извън тях (с много малко изключения, като например Black Mirror).

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

А книгите…
Книгите са огромно количество. Да прочетете 1 GB чист текст ви трябват 20на години (сметката е, че 1 страница е около 4kb, което прави ~250000 страници, дори при моя темп на четене са 5 години). Само в проекта Гутенберг има 21GB книги (проектът, който събира книгите с изтекли авторски права), да не говорим за количеството други архиви, като например libgen (където има около 10 милиона книги). Според една сметка на google до 2010 е имало 129 милиона книги, които няма как да бъдат прочетени от един човек, дори един процент е непосилно число. Аз, с много желание, за целия си живот има шанс да прочета най-много 10000 книги, ако се старая много.
Книги може да четете навсякъде, без да пречите на хората (с изключение на случаите, в които четете докато някакви хора ви обръщат внимание).
Разнообразието на идеи в книги е най-голямото съществуващо – всички идеи тръгват от някакви книги или ги има в такива, и има нещо като правило 34 на internet-а (което гласи, че ако има нещо, то има порно с него) – ако нещо съществува, то има книга по темата. При 129 милиона книги не е трудно.
Има и формати, които работят без ток – има хартиени книги, работят без ток, само със светлина (даже не е задължително да е слънчева), не им трябва даже internet. Предполагам, все още сте виждали такива напред-назад, ако ще да е само да си подпирате монитора :)
И книгите са най-близкото нещо, което имаме до телепатия. Малко по-нататък ще ви го покажа :)

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

Развива важното за нас въображение. Ето един цитат:
‘Oh, you know for years we’ve been making wonderful things. We make your iPods. We make phones. We make them better than anybody else, but we don’t come up with any of these ideas. You bring us things and then we make them. So we went on a tour of America talking to people at Microsoft, at Google, at Apple, and we asked them a lot of questions about themselves, just the people working there. And we discovered that they all read science fiction when they were teenagers. So we think maybe it’s a good thing.’

Идва от първата организирана от държава (Китай) конференция за фантастика. Събрали там разни писатели и свързани хора, и Нийл Геймън, който бил там попитал местен партиец – защо правят такова нещо, никъде другаде не бил виждал нещо подобно. Отговорът е цитатът по-горе, че колкото и да са добри китайците в копирането или правенето на техника, нищо от това, което правят не е измислено там. Та, някакви хора отишли, разпитвали всякакви работещи из Силициевата долина и общото, което намерили било четенето на фантастика в ранна възраст. Та, може би е нещо хубаво?
Предположението е, че това развива (важното за нас) въображение.

Също така, от книгите могат да дойдат много нови идеи и насоки (за което имам три пълни слайда):

Фантастика с вампири в космоса ме накара да седна и прочета много неща по темата за човешкото съзнание, мислене, свободната воля и свързаните теми. Беше доста странно, понеже попаднах на нея от thread в един блог, където се питаше за наистина важна книга от последните 10 години, и там много хора казваха – тази книга е страхотна, не се плашете от вампирите. Ще я спомена даже по-нататък пак.

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

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

“Fight club” и темата за консумеризма – книгата е прилично по-добра от филма (въпреки че филмът много се старае).

Dead air на Iain Banks и как се бори човек с идиоти е също доста забавна.

И да, наистина представата ми за армията и казармата отвътре все още се базират на “Приключенията на добрия войник Швейк” на Ярослав Хашек. На мен казармата ми се размина, но си мисля, че нямаше много да ми мръдне представата…

“Little brother” и “Homeland” на Кори Доктороу дадоха интересни идеи за следващите протести (каквато е и целта им, те са не толкова книги, колкото наръчници).

“Махалото на Фуко” и “Пражкото гробище” на Умберто Еко са може би най-закопаващите книги за конспиративните теории.

“Сатанински строфи” на Салман Рушди ме накара да се ровя повече в Исляма и да се опитам да разбера какъв точно им е проблема на тия хора с книгата.

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

Крайтън и Хейли са ме карали да се интересувам от инфраструктурата на всичко – заводи, летища, болници…

Като пример не за мен – Артър Кларк е измислил комуникационните спътници.

И всякакви други неща, които не ми е преписват от слайда :)

Разбира се, може да четем просто за удоволствие. Спомням си как първата книга, която наистина ми хареса (“Откраднатата баба” на Атанас Мочуров – не помнех автора, ама я издирих по заглавието) съм я чел 39 пъти, просто щото ми харесваше. Идея си нямам защо съм ги броил, но мисля, че в един момент я знаех почти на изуст (трябва да съм бил на 6-7-8 години).
Спомням си една такава случка, като беше излязла “Нощната стража” на Тери Пратчет, със съквартиранта си я бяхме взели и вечерта като се прибрахме, седнахме да четем, всеки в неговата стая. По едно време аз свърших книгата, погледнах навън и без да се усетя, казах на глас “Брех, то се е съмнало!”. От другата стая чух “А, вярно бе!”…

Дори самият език може да достави огромно удоволствие. Ето малко цитати:
(дължа бира на Андрей, щото се сети от къде са няколко от тях)

“И наистина, бай Ганьо разлюти супата си до такваз степен, щото един непривикнал човек би се отровил.”
Тоя цитат винаги си го спомням, като ям шкембе чорба.

“The house had four windows set in the front of a size and proportion which more or less exactly failed to please the eye.”
(“Пътеводител на галактическия стопаджия”)

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

“What is a flower? A giant sexual organ in its Sunday best. The truth has been known for a long time, yet, over-aged adolescents that we are, we persist in speaking sentimental drives about the delicacy of flowers. We construct idiotic phrases like “So-and-so is in the flower of his youth”, which is as absurd as saying “in the vagina of his youth””
(Амели Нотомб, “Любовен саботаж”)

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

“Political language is designed to make lies sound truthful and murder respectable, and to give an appearance of solidity to pure wind.”
(Оруел, разбира се)

“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying ‘End-of-the-World Switch. PLEASE DO NOT TOUCH’, the paint wouldn’t even have time to dry.”
(Пратчет)

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

Разбира се, чувал съм и доста оплаквания. Можем да започнем с “ама това не ли бягство от реалността”, и ще отговоря пак с цитат (който е цитат от някой друг): “C. S. Lewis wisely pointed out that the only people who inveigh against escape tend to be jailers.” (Нийл Геймън). Интересно, че като човек чете (non-fiction) книги за правилата по разни тоталитарни лагери и затвори (съветските са един много добър пример), там всякакви такива неща като личен живот и бягане от реалността са максимално забранени (има един особено добър пример в румънските “превъзпитателни” лагери), като успяват да потрошат психически сериозна част от хората. Да се чуди човек Оруел без да е бил там как толкова добре ги е описал…

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

Чувал съм хора да казват, че книгите са им скучни. Това значи, че четат грешните книги – при толкова много съществуващи не е особено възможно да няма нищо интересно. Има всякакви странни неща, включително преди няколко години някой написа “Гордост и предразсъдъци със зомбита”…

А защо това подзаглавие, къде е дрогата? Пробвайте :) Става ясно много бързо, нуждата да разберете какво става, да се нарадвате на езика, на идеите… Доколкото знам, хората се лекуват от желанието си за четене чрез умиране (за разлика от опиатите, където поне има програми и институции да помогнат). Винаги има желанието да се намери още нещо такова, толкова интересно и забавно (а защо не и повече?). В статистиката на goodreads (които са не-чак-толкова-голяма социална мрежа) за миналата година в reading challenge има 1,722,620 участника и 29,258,154 прочетени книги. Забавното е, че аз, дето чета по около 100 книги годишно, не влизам даже в топ 20-30%, щото има хора, дето четат по 900…

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

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

> – How long do you want these messages to remain secret?[…]
> – I want them to remain secret for as long as men are capable of evil.
“Cryptonomicon”-а на Нийл Стивънсън мисля, че съм споменавал и преди – в книжните си лекции в initLab и в кило други post-ове. Криптография, валути, втората световна война, модерните крипто-пънкове, Алан Тюринг, и просто радост за душата. За всички, на които е харесала Стивънсън е написал Бароковия цикъл, който е три такива тухли в края си има спор между Нютон и Лайбниц на темата за свободната воля. От нея може да ви станат интересни много неща.

> ‘And what would humans be without love?’
> RARE, said Death.
Чудех се и не можах да избера една книга на Тери Пратчет, за това препоръчвам целия. Имаше проблем с част от преводите му, в оригинал е прекрасен, пробвайте го.

> “Bill could smell Its breath and it was a smell like exploded animals lying on the highway at midnight.”
Стивън Кинг е човекът с телепатията. В книгите му е пълно с такива изречения, които в един момент започвате да си представяте. Има хора, които твърдят, че не е сериозен писател, понеже пише там някакви си популярни ужаси, но истината е, че той е един от наистина големите майстори на езика и на това да бръкне някъде във вас. Може би и буквално :) От него препоръчвам като за начало “Мъртвата зона”, “То”, “Зеления път”, или каквото изобщо си харесате. Има много филми по него, и сполучливите са точно защото са успели да предадат телепатията достатъчно добре на екрана.

> “This is how you communicate with a fellow intelligence: You hurt it, you keep on hurting it, until you can distinguish the speech from the screams.”
Blindsight на Peter Watts (“Слепоглед” на български, не съм гледал как е превода) е книгата с вампирите в космоса и една от най-издържаните научно фантастики, на които съм попадал. Авторът е океански биолог, работил по специалността си 10на години, публикувал и т.н., и решил в един момент да мине към фантастиката. Това е първа книга от втората му поредица, и това беше много замисляща книга, в която намерих и много от неща по темата за изкуствения интелект, които преди това бях виждал в “Новият разум на царя” на Роджър Пенроуз (математик, книгата е научно-популярна на темата докъде може да стигне изкуствения интелект, с прилично количество математика).
А за вампирите обяснението е, че те са вътрешно-видов хищник, който се храни с хора, има много добро зрение, и е изчезнал когато хората са започнали да строят къщи, понеже ако вампир види прав ъгъл, му се задействат едновременно твърде много от зрителните рецептори, получава се претоварване и нещо близко до припадък. За останалото препоръчвам да хванете книгата :)

> “Governments always commit their entire populations when the demands grow heavy enough. By their passive acceptance, these populations become accessories to whatever is done in their name.”
“Експериментът Досейди” на Франк Хърбърт. Повечето хора знаят за “Дюн”, но това също си заслужава да се прочете, поне като идея за посоката, в която може да тръгне дадено общество под натиск (и която може да отговори защо хората от много потиснати общества успяват да “hack”-нат тези от по-свободните, на по-прост език защо престъпността в Европа след 1989 е осново от източно-европейски произход).

> “We are a wretched, petty species, and we have been given power to destroy ourselves with.”
“Worm” на Wildbow е интересен случай. Ако не беше толкова добро, и толкова трудно за оставяне, не знам дали нямаше да застрелям човека, който ми я препоръча – книгата е около 5000 страници, и не дава възможност да я оставиш. И докато с други книги това е в общи линии да не се спи една нощ, тук това беше две седмици непрестанно четене до ранните часове. Може да се намери online на url-то, и я препоръчвам на всички, не само защото искам и други хора да преживеят същото нещо :) Може просто да я започнете, то не е нужно много…

Имаше няколко въпроса след лекцията:
Функциониращ адрес на libgen – не се намира трудно, има един, завършващ на .rus.ec….
Техники за бързо четене дали използвам – мисля, че само една, че не субвокализирам (т.е. не си произнасям на ум думите), но не помня как съм го научил, случи се във ваканцията ми между първи и втори клас, просто започнах да чета по-бързо. Има някакви начини и доста информация по темата, може да е полезно да се пробва. Скоростта на четене много зависи и от количеството информация, има неща (като фентъзита), които могат да се четат много по-бързо, понеже просто информацията вътре не е толкова много.
Ако до края на живота си съм принуден да избера една книга, която да препрочитам, коя ще е – никаква идея. Мислих, мислих, но ще трябва да е нещо много по-дебело от Worm …
Минавало ли ми е през ума да пиша някаква книга – аз не пиша особено добре, а и това иска доста време и спокойствие, които нямам. Доколкото знам, е нужно да напишеш около милион думи текстове, за да свикнеш да пишеш добре, не знам дали съм стигнал до там. Иначе, многото четене е изискване за доброто писане, но не е достатъчно.

На 23ти юли Data Science Society организираха лекция на Преслав Наков, “The web as a training set”. Записът е готов, одобрен и може да се свали от тук.

Водих лекция на темата инфраструктура на “дни на софтуерната архитектура”. Нещо не се хареса на публиката, но се надявам да е по-смилаема в текстов вид.

Ето и презентацията.

[slide 2 Кой съм аз]

Здравейте.

Казвам се Васил Колев и съм дошъл да ви говоря по темата за инфраструктурата.

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

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

[slide 3 За какво ще ви говоря]

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

[slide 4 За какво няма да говоря]

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

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

[slide 5 Какво имам в предвид под “state”]

И ще искам да изясня един-два термина, които ще споменавам от време на време в лекцията си.

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

[slide 6 Какво е инфраструктура?]

Терминът “инфраструктура” буквално значи “структурата отдолу”, т.е. това, на което се крепите (например подът и столовете в залата са инфраструктура, както и климатизацията и, електричеството и т.н.). Може да мрежите, които ползвате, може да е директно разни услуги (всичките “cloud” неща могат да се кръстят “infrastructure as a service”), но е нещо, което не контролирате пряко и на което разчитате.

То може да е и на сравнително високо ниво, като база данни, web или application сървър, в зависимост от това вие къде се намирате.

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

[slide 7 CAP теорема]

И нещо доста важно, т.нар. CAP теорема – която казва, че ако имате дистрибутирана система за съхраняване на state (т.е. например база данни), тя може да има само две от следните три свойства: консистентност (данните да са същите и на двете места), достъпност (винаги да работи) и partition tolerance (да може да работи при разцепване). Има някои подробности по дефиницията на консистентност и доколко съвпада с дефиницията от реалния свят, но за нашите цели теоремата важи в този си вид, и накратко ни казва “трудно е да се направи дистрибутирана база данни”.

[slide 8 ]

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

Забелязвате ли как съм кръстил схемите “сферичен кон”? Това, защото в реалния свят системите изглеждат ето така:

[slide 9 ]

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

[slide 10 Каква е моята работа]

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

[slide 11 ]

Single points of failure са може би основния проблем, който съм виждал в практиката.

[slide 12 ]

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

[slide 13 Как се създават в софтуера]

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

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

[slide 14 Как се избягват]

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

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

[slide 15 Дистрибутиран/подсигурен state (1/2)]

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

[slide 16 Дистрибутиран/подсигурен state (2/2)]

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

И да, всички искаме една безкрайна SQL ACID база данни, но такава няма – дори това, което ни предлагат за огромни пари има някакви странни ограничения, в които се удряме докато ги ползваме.

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

[slide 17 Всичко останало]

Та, както казах всичко останало се решава лесно с дублиране и load balancing.

[slide 18 ]

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

[slide 19 TL;DR]

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

[slide 20 ]

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

[slide 21 ]

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

[slide 22 Накъде вървим]

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

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

Като пример мога да дам, че в момента един от най-бързите архитектурни модели за правене на сървъри, които process-ват много заявки е на принципа на co-routines, познати в windows-кия свят като “fibers”, а в erlang като “actors”. Идеята е, че вместо да имате цели thread-ове, които да изпълняват всеки по дадена задача, имате гигантско количество малки задачки, които се schedule-ват и изпълняват когато им е възможно. В книгата “The performance of open-source applications” има два такива примера (за съжаление на erlang и на haskell), но ако някой се интересува, мога да разкажа за такова решение с човешки езици за програмиране, която трябва да се появи като open-source някой ден.

[slide 23 Какво следва]

Това ни води до няколко важни неща, идващи от паралелното програмиране.

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

Трябва да избягваме зависимостите, доколкото можем, както и създаването на bottlenecks – единични компоненти, през които трябва да мине всичко (и които освен това ще са single points of failure).

[slide 24 ]

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

[slide 25 Всичко е мрежа]

Например вече всичко е мрежа. От вътрешната архитектура на процесорите, през дънните плати, SATA/SAS – всичките тези технологии представляват някакви мрежи в звездоподобна технология, със switch-ове и router-в тях, по някакви собствени протоколи. Да не говорим, че вече почти нищо не ни е локално (например базата данни ще ви е на същата машина само ако сте много малка услуга).

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

[slide 26 List of network fallacies]

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

[slide 28 Internet и мрежите не са reliable]

Да почнем от там, че internet и мрежите като цяло не са reliable. Нямате гаранция за нищо, всичко е best-effort и за да постигнете някаквите си нужни гаранции е необходимо да вкарате логика при вас, която да се справя с такива проблеми.

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

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

[slide 29 Да забравим латентността]

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

Един прост пример, който мога да дам е, че по принцип SSL протокола прави от 3 до 6 round-trip-а, т.е. отивания на пакети от единия до другия край, за да осъществи връзка. По принцип ако си говорите със сървър в същата държава, едно RTT е под 20ms, и това няма да се усети лесно като проблем, но ако говорите от Европа до Щатите и едно rtt е 150ms, изведнъж тази разлика става наистина осезаема – потребителите започват да усещат забавянето и да не искат да ви ползват сайта. Това може да се реши в софтуера с настройка на самия SSL протокол, но малко хора се занимават да му обръщат внимание.

[slide 30 Твърде много данни по твърде малка тръба]

Трудно ще намерите мрежа, която да достига скоростта на копирането в паметта. Лоша идея е да се опитвате да прекарвате много данни от едно място, или като цяло да прекарвате ненужно количество данни през някакво тясно място от мрежата.

Има неща от типа на remote dma – т.е. да накарате две системи да си предават данни, вместо да ги копирате през себе си. Може да погледнете bittorrent протокола и какво умее – в момента това е най-бързия начин за прехвърляне на информация до много места в internet.

[slide 31 Голи данни по пробита мрежа]

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

На теория трябва да се криптират само важните данни, но понеже няма начин да се определи кои данни са важни, е далеч по-лесно и по правилно да се криптира всичко.

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

[slide 32 Мрежата ще отговаря на всичките ви изисквания]

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

[slide 33 … и т.н.]

Мрежите са нещо прекрасно, те са бъдещето, пътя, истината и живота :) Могат много да ви помогнат, могат да ви съсипят и е важно да ги познавате в подробности.

[slide 34 ]

И ще поговоря малко по темата дизайн на системи, понеже има голямо отношение към инфраструктурата и комуникацията с нея. Ще започна с нещо просто, разликата м/у store&forward архитектури и pass-through.

[slide 35 Дефиниция]

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

[slide 36 Примерна система]

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

[slide 37 Предимства и недостатъци]

Тук и двата начина си имат предимства и недостатъци. Pass-through има по-ниска латентност, което понякога може да се окаже наистина важно, но от друга страна може да се претовари по-лесно и е по-чупливо от store&forward. Pass-through и са по-сложни за дистрибутиране.

[slide 38 Извод]

Pass-through като цяло е доста по-ефективно решение, ако ви е нужна скорост, но препоръчвам store&forward за всичко, което не е критично – може да издържи доста повече на проблеми и по-лесно се възстановява след проблеми.

[slide 40 ]

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

[slide 41 (почти) Всичките ни системи са комплексни]

Ние почти нямаме линейни системи в практиката. Всичко, което правим има странни интеракции в него и е огромно като размер. Дал съм пример как Airbus A380 без да броим софтуера има 4 милиона компонента, а само linux kernel-а е над 12 милиона реда код, или ако го компилираме, в себе си има над милион условни прехода.

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

[slide 42 Тъжни факти]

Ние на практика нямаме толкова голяма система, която наистина да разбираме, която да може да бъде разбрана от един човек – а от друга страна очакваме, че всеки един програмист може да се справи със съществуващите ни системи. Като комбинираме това, че средно имаме по 10-15 грешки на 1000 реда код в изтествани и release-нати продукти е учудващо, че нещо изобщо работи.

В механичния свят е по-лесно да направим система, с чиито failure mode-ове да сме наясно при отпадане на един или два компонента – например сме сравнително наясно с двигателите на колите, но реално погледнато всичко по-сложно от това ни е сложно.

[slide 43 Може да се мине със следния цитат]

Винаги обичам да давам този цитат. За който не е запознат, Jim Gray е човекът, измислил голяма част от теорията за backend-ите на базите данни, които ползваме в наши дни (например цялата ACID идея).

[slide 44 Изроди]

Изводите мисля, че са ясни, нека да правим прости неща, доколкото можем, и да се стремим към простота. Неколкократно съм виждал система да бъде реализирана добре в 10к реда код, и лошо в 100к, и си мисля, че си заслужава усилието да правим минималистично нещата.

[slide 45 ]

И ще приключа с нещо наистина страшно.

[slide 46 Какво е bitrot]

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

[slide 47 Статистика от wikipedia]

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

[slide 48 Случки от реалния свят]

В една система с 395 милиона файла имаха около 300 грешки в рамките на месец, и в последната седмица – 3 (това беше проверка по sha1 checksum-а на файловете). Това са свестни, малко по-стари сървъри, с raid5 масиви, а софтуерът е съвсем малко и много внимателно изтестван и прегледан – и все пак се появяват такива проблеми. Скоро 1PB няма да е огромно число, а нещо нормално и очаквано, и можем да очакваме при всички ни да се видят такива проблеми.

И нещо още по-неприятно – едни приятели имат софтуер, на който правят сериозни regression test-ове. В техния lab се появили някакви crash-ове, които се появявали по странно време без никаква логика, и след известно време открили, че това се случва само на сървърите без ECC памет. Машините имали 16-32 GB памет и не са били купувани на битака :)

[slide 49 row-hammer exploit]

И, нещо съвсем скорошно, т.нар. row-hammer exploit, че ако пишете много някъде по паметта, можете да flip-нете бит на друго място. С това даже бяха успели да напишат и exploit, с който да може през browser-а и sandbox-а му да се излезе и да се получи root достъп.

[slide 50 Инструкции за цивилното население]

Това е ужасно.

Няма хубаво решение на тия проблеми – реално няма много research как да работим със счупен хардуер – но трябва да знаем, че ще ни се случи. Решенията, които имам са съвсем малко (освен първото) – максимално прости системи, failfast – т.е. да се спира при първия възможен шанс, ако се открие нещо такова, и run-time проверки за коректност (познати ви като assert-и), за да може да се ограничат последиците от проблема.

[slide 51 ]

И няколко книги, които могат да са ви полезни:

* “The Architecture of Open-source Applications”, vol. 1 и 2
* “The Performance of Open-source Applications”
* “Beautiful Data”
* “Normal Accidents: Living with High-Risk Technologies”, Charles Perrow
* “Cryptography Engineering”, Schneier, Ferguson & Konho

(презентацията)

[slide 2 Идеята за тази лекция]

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

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

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

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

[slide 3 Защо ние го говорим това]

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

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

[slide 4 Кои сме ние]

Минутка за реклама – ние сме cloud storage услуга, направена правилно. Startup сме, има ни от около година, имаме около 600k потребители и 600TB заето място и правим всякакви интересни неща, за които обаче ще ми трябва тричасов слот, че да ги изброя :)

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

[slide 5 Authentication]

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

[slide 6 Стандартен метод за auth]

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

Което е лоша идея, понеже паролата ви минава по мрежата в някакъв вид, и не може да сте сигурни дали някой не подслушва или дали някой не се прави на отсрещния сървър.

[slide 7 Правилен метод]

Правилният метод, който използва един прост криптографски примитив, се нарича challenge-response. Има и реализация в самия HTTP протокол, т.нар. digest authentication, както и в много други системи (например SIP). В web твърде рядко се среща, поради нуждата от още една заявка (или поради неинформираността на разработчиците).

Работи по следния начин:
Сървърът ви генерира nonce – някаква стойност, която е произволна, няма да се повтори пак. Смятате криптографски hash в/у нея и паролата и изпращате резултата на сървъра. Той от своя страна може да направи същото изчисление и да разбере, че вие знаете същата парола.

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

Методът е по-бавен от другия, понеже изисква още една заявка (да си вземете nonce, с който да работите), т.е. вкарва още един round-trip. Това не е проблем, понеже това така или иначе не трябва да е особено бърз процес – т.е. колкото по-бърз е, толкова по-лесно може да се използва за brute-force атаки.

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

[slide 9 Plaintext в базата данни]

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

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

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

[slide 10 Първи лесен (и грешен) вариант]

Първото решение на проблема, което е лесно и грешно, е просто да се съхранява някакъв криптографски hash на паролата – md5 (много-лоша-идея) или sha1 (не-толкова-лоша идея). Това се атакува тривиално с rainbow таблици.

Съвсем накратко, rainbow таблиците са пресметнати таблици с (почти) всички възможни пароли, така че лесно да може да се намери в тях някакъв валиден string, който да отговаря на дадения hash. Също така имат метод за съхраняване на по-малко данни, та по принцип за md5 таблиците са под 2TB, за sha1 има таблици с повечето пароли пак в някакъв такъв размер.

Накратко – лоша идея.

[slide 11 Втори лесен (и правилен) вариант]

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

Идеята е проста, генерираният hash да е на някакъв salt и паролата. Salt-ът се подбира да е различен за всяка парола, и се слага преди получения hash. Така лесно може да се пресметне, но не може да му се генерира rainbow таблица (т.е. ако се генерира, ще трябва да съдържа и възможните salt-ове).

[slide 12 Трети не-толкова-лесен (но правилен) вариант]

Третият вариант, който може да се използва (и който сме реализирали при нас) е да се пази “частичен” hash на паролата (т.е. по-точно пълния state на hash функцията) и някакъв salt, така че да може и да се реализира challenge-response. Това ни отне малко повече време за реализация, но така не пазим пароли в plaintext и можем да реализираме challenge-response, за да гарантираме максимална сигурност на потребителите си.

Много близко е до lenghtening атаката в/у хешове.

( Корекция след самата лекция: Реално погледнато, challenge-response може да се реализира дори с хеширани пароли по предишния начин)

[slide 13 Четвърти (велик и труден за правене) вариант]

И последният метод, който дава най-голяма сигурност, и който не съм виждал реализиран никъде, освен на една лекция. Идеята му е в общи линии като на password-authenticated key agreement протоколите, повечето от които поне доскоро бяха патентовани и като цяло не се срещат особено често.

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

За съжаление не съм виждал никъде реализация на схемата. Описанието и видях в една лекция на Дан Камински преди няколко години.

[slide 14 Further reading]

И понеже темата е доста обширна, може да потърсите този стандарт – password-based key derivation function, както и да погледнете конкурсът за нови такива алгоритми за съхраняване на пароли, може да са ви полезни.

Специално PBKDF2 показва едно доста важно свойство на всички тези схеми. Важно е проверката на паролата да не е максимално бързо действие, а да отнема някакво малко, но достатъчно време, така че да да се направят brute-force атаките по-трудни.
Самият PBKDF е схема за прилагане на хеш функция много пъти (1000, 10000 или нещо такова) върху входни данни и salt, така че от това да се получи някакъв набор битове, които да се използват или като съхранена парола, или като ключ за нещо друго. Поради големия брой действия, които няма как да се направят по-лесно, лесно може да се сметнат параметри, които да ви дадат нещо като 10ms за извършване на сметката, което да доведе до невъзможност да се правят повече от 100 теста в секунда на един core.
М/у другото, пример за използвана такава схема е WPA при wi-fi мрежите – там ключът за комуникация се генерира с pbkdf2 с 1000 пъти sha1 и essid-то (името) на мрежата за salt. Ако някой е пробвал да чупи такива пароли знае, че върви доста по-бавно, отколкото просто на хешове.

[slide 15 Комуникация]

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

[slide 16 Стандартни неща]

По принцип всичко живо използва JSON и HTTP. Те са бавни протоколи, текстови, с много overhead и не-чак-толкова удобни за parse-ване (добре поне, че има такива библиотеки в почти всеки език).

Да не говорим, че HTTP е мислен за съвсем различни неща от тези, за които се използва в момента.

[slide 17 Трябва алтернатива]

Добре е да имаме алтернативи. Не всичките ни клиенти са browser-и, но всички са принудени да ползват интерфейси, писани за тях, което е доста неприятно и на моменти – много неефективно (но понеже хората са свикнали, вече не обръщат внимание). Най-добрият пример е какво ползват мобилните приложения – все http базирани api-та, а те уж са устройства, които трябва да пестят от батерия и CPU колкото се може повече.

Дори в самите browser-и вече не е това единственият подходящ и ефективен начин – в момента навлизат websockets и webrtc, точно заради това.

(имах въпрос от публиката после защо нещо не съм много оптимистично настроен по темата webrtc, човекът (Лъчко всъщност) се надявал да може да замести skype – понеже това, което реално успява да прави skype е да работи през всякакви мрежи и NAT-ове, което за останалата телефония е сложно и не се справя толкова добре. Webrtc-то още не е стигнало да бори наистина сериозно такива проблеми и вероятно ще му трябва доста време, докато започне да се справя с тях).

[slide 18 Примерен binary протокол]

По тази причина ние сме направили допълнителната възможност да може да се комуникира с интерфейсите ни през просто binary api.
Като казвам просто – то наистина е такова, описанието му се събира на няколко страници, реализацията (която имаме публикувана в github) е 700 реда на C или 536 реда на java, заедно с коментарите. Има много по-малко overhead, и се обработва много лесно на всякаква платформа. Също така в себе си има няколко хитрини, например ако в даден пакет определен string се среща повече от веднъж, съдържанието му се пази само на едно място и останалите са reference.

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

[slide 19 QUIC и пътят напред]

И да слезем по-надолу – един от проблемите в съществуващите протоколи е, че осъществяването на връзка е бавно. Нужни са 3 пакета (и 1 RTT), за да се осъществи връзка м/у две точки по TCP, а когато добавим SSL/TLS, добавяме и още 2-3 RTT-та в зависимост от някои настройки на протокола.

Едно от съществуващите решения е разработка на google, казва се QUIC – Quick UDP Internet Connections, протокол, който замества комбинацията от TCP+TLS. Има в себе си всички полезни неща от TCP, като правилните алгоритми за напасване на скоростта и congestion avoidance, но криптирането в него е по подразбиране, и осъществяването на връзка става в рамките на едно rtt, заедно с избирането на ключове и т.н..
Има също така интересни feature-и, като например multiplexing – да се обработват няколко заявки в една връзка (като в SCTP). Друго нещо е forward error correction, да може да коригира грешки в пакетите или изгубени такива по вече пратени данни.

Ние сме в процес на разглеждане на протокола, ако ни хареса достатъчно, мислим да го използваме. В момента има поддръжка в chrome и opera, ако придобие достатъчно разпространение, ще реши проблема и с firewall-ите. Разработката на google е пусната под BSD лиценз, и е сравнително малко код на C++, та би трябвало скоро да се появи и на други места.

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

[slide 20 Употреба на SSL/TLS]

Ако не сте живели под камък в последната година и половина, вероятно сте наясно защо е важно да се ползва криптиране на връзките и по принцип SSL/TLS.
(ако сте, питайте търсачките за Edward Snowden)

Вече повечето услуги имат поддръжка за TLS – отне години и доста лобиране/мрънкане от страна на общността, но е често срещано. Не винаги е реализирано правилно обаче…

[slide 21 Правилна употреба на SSL/TLS]

Първото е, че в твърде много случаи не се обръща внимание на шифрите, които се използват, съответно сигурността на връзката с някои места е почти същата като за без криптография. Пример за това е как преди около година Android смениха списъка си с поддържани шифри/алгоритми и приоритетите им, понеже “в java стандарта било така” (предишния им списък беше взет от openssl). Java 6 е стандарт на около 10 години и в новия е оправено…

Друго важно нещо е т.нар. forward secrecy – това е възможността след осъществяването на връзката двете страни да разменят през DH или друг алгоритъм ключове, които са само за тази сесия и се забравят след нея. Така се подсигуряваме, че дори да изтекат главните ключове на сървъра, то записаната от преди това комуникация няма да може да се декриптира и ще остане тайна.

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

И разбира се, SSL/TLS не е панацея, и те имат собствени проблеми (като например heartbleed наскоро).

[slide 22 SSL/TLS Session caching]

За услуги, които имат повече от един физически сървър, който поема криптираните сесии (но на същия domain), има друг полезен момент – да се реализира глобален SSL session cache, който да пази определени параметри, за да не се renegotiate-ват всеки път. Това спестява едно RTT от всяка заявка и определено се усеща.

За целта може да ви се наложи да използвате някакъв backend storage (memcache или redis), в който всичките ви сървъри да пазят тези сесии, но да се подкара не е особено сложно и може да има видим ефект за потребителите ви.

[slide 23 Privacy]

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

Примерът за разкриването дали даден файл (което btw е проблем, който идва основно от дедупликацията в повечето такива услуги) е как един определен service можеше да му кажеш “аз ще ти кача файл с тоя MD5” и той казваше “а, аз го имам, заповядай”. Това за известно време сериозно се използваше за share-ване на файлове без реално да се вижда какво става…

[slide 24 Не всички клиенти са равни]

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

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

[slide 25 Предаване на параметри]

Например, предаването на параметри. При нас параметър може да бъде предаден където ви е удобно – като GET, като POST, в URL-то на POST-а, или в cookie. Даваме ви възможност за прострелване в крака, но от друга страна ви даваме начин да ни ползвате от възможно най-простите клиенти на тоя свят, които нямат POST.

[slide 26 обработка на request-и в движение]

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

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

[slide 27 blatant self-promotion]

И оставащата част от презентацията е хубави неща, които са специфични за cloud storage услуги, или “защо ние сме по-добри от останалите”. Не само ние правим тези неща, но май само ние правим всичките.

[slide 28 Thumbnail combining]

Нещо, което пак идва от тъпата брадва на HTTP/AJAX и компания – ако имате да покажете галерия от thumbnail-и, няма смисъл да ги дърпате един по един. Много по-ефективно е да може да ги комбинирате в един голям файл и да ги показвате, докато пристигат.

Конкретните методи за това са доста грозни (thumb-овете, изредени по един на ред в base64 и се декодират после), но си личи промяната в скоростта.

[slide 29 On-the-fly zip]

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

[slide 30 Rsync-подобен протокол]

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

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

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

[slide 31 Видео с напасващ се bit rate]

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

[slide 32 Файлови операции]

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

[slide 33 Други готини неща за в бъдеще]

Тук исках да кажа и други неща, но не ми стигна времето да ги извадя.

Това е един план за светлото бъдеще (в рамките на годината) – да направим end-to-end криптиране на файловете на потребителите, т.е. да им дадем функционалност, чрез която те още при себе си да криптират всичко и да не можем да го четем, както и да са сравнително сигурни, че не не им подменяме или омазваме файловете. Би трябвало всички да го правят – реално погледнато няма причина нещата, които са лични за потребителя да могат да бъдат известни на оператора на услугата, и има доста разработки по въпроса.
Например, има дори няколко paper-а по темата за криптирана база данни – тя стои криптирана на един сървър (който няма ключовете), вие пращате криптирана заявка, сървъра прави някакви сметки и ви дава отговор от вашите данни, който също е криптиран и който само вие може да разберете. Все още нещата са в начални стадии, но са една добра идея за бъдещето.

[slide 34 Отворени сме към други идеи]

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

Приемаме всякакви корекции и идеи – по принцип имаме натрупана работа като за 3-4 години напред, но това още не е успяло да ни уплаши :)

(презентация)

[slide 3 Често срещана практика]

(този трик вероятно има някакво стандартно име, което аз не знам, цялата лекция ми хрумна една вечер докато не можех да спя и така и не се зарових)

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

[slide 5 просто решение – подпис с криптографски hash/hash mac]

Проблемът има просто решение, чрез криптографски (hash) подписан token, от който може да се извади цялата информация, без да е нужно да се гледа някакъв state. Генерира се тривиално, като до информацията се долепя един HMAC подпис с някакъв secret, който ви е познат на вас.
(hmac е метод за прилагане на hash функция, например sha1. Не е добра идея да се използва директно SHA1 или нещо от същото семейство, понеже подлежи на lengthening атака, но може да се ползва SHA3)

Така тази информация се проверява тривиално, и не изисква да пазите каквото и да е и да могат да ви препълнят някакви таблици, да генерират писания в базата и т.н.

[slide 6 Инвалидация на token]

Схемата има един проблем – няма прост начин да се инвалидира. За това има няколко различни workaround-а:
Имаме timestamp, при който знаем кога изтича token-а и като цяло го правим да е валиден за кратко.
Слагаме в него нещо, което потребителя може да промени и така да го инвалидира (например паролата му, чрез смяната и може да ги направи невалидни).
Можем и да пазим кога последно сме генерирали token и да не признаваме по-стари (или по-нови) такива.
В общи линии последните две неща ни карат да питаме външен източник, когато проверяваме token-а, но пак ми дават възможност да държим много по-малко state.

[slide 8 VERP ]

За всички, които трябва да пращат поща и да знаят дали адресът не е bounce-нал – проста схема, в която пишем в Return-path: адресът, на който сме пратили писмото и по отговорите на този адрес знаем кой точно не се е получил. Към това лесно се добавя един прост подпис, така че да не се получават случайни писма при някакво глупаво изчерпване.

[slide 9 TCP Syncookies]

Вече default на всички tcp/ip стекове. Идеята е съвсем проста – ISN (initial sequence number) на сесията, който връщаме в SYN+ACK пакета представлява hash на secret и още няколко неща, така че когато получим третия пакет от handshake, можем да сме сигурни, че този клиент е искал да се свърже с нас.
(За повече подробности потърсете за SYN flood и защита от него).

[slide 10 client-side session]

Също така можем да спестим място от потребителски сесии – можем да пазим само последен timestamp и нищо друго, а самата сесия да е в cookie при потребителя и да не ни интересува. Така можем да сме сигурни, че ние сме му я подали и че не съдържа нещо, което не сме искали.

В четвъртък (15 май), от 19:30 в initLab ще правя пак workshop за озвучаване/записване (като за конференции).

This is my talk from RIPE-SEE3, on the deployment of IPv6 in Sofia University. The presentation can be downloade in pdf or odp format.

I’ve put the slide number or the notes/comments I have in [], the rest is as close to what I said as I remember, with some corrections.

[1]

Hello. I’m going to talk about the IPv6 deployment in Sofia University. It’s an important example how this can be done on a medium-to-large scale, with no hardware upgrades or hidden costs.

This presentation was prepared by Vesselin Kolev, who did most of the architecture of the network there and was involved in its operations until recently.

(I want to clarify, we’re not the same person, and we’re not brothers, I get that question a lot)

[2]

Please note that I’m only doing this presentation, I was not involved in the deployment or any network operations of the university’s network.

[3]

These are the people that did and operated this deployment. Most of them aren’t there any more – Vesselin Kolev is at Technion in Israel, Nikolay Nikolov and Vladislav Rusanov are at Tradeo, Hristo Dragolov is at Manson, Radoslav Buchakchiev is at Aalbord University, Ivan Yordanov is at Interoute, Georgi Naidenov is a freelancer. Stefan Dimitrov, Vladislav Georgiev and Mariana Petkova are still at the university, and some of them (and some of the new people there) are at this conference, so if you have questions related to the current operations there, they’ll probably be able to answer better than me.

[4]

So, let me start with the addressing.

[5]

This is the current unicast network that’s in use in the university. It was assigned around February 2011 and was used from the 11th of February 2011 onwards. It’s a /47, later on I’ll explain why.

Also please note that the maintenance of the records in the RIPE database for the network is done only with PGP-signed emails, to protect this from hijacking. As noted by one previous speaker, there are a lot of cases in RIPE NCC, where bad people try to steal prefixes (as their value is rising), and that’s possible mostly because there aren’t good security measures in place in a lot of LIRs.

[6]

Before that, the university used a /35 from SpectrumNet (since then bought by Mobiltel), until they got their own allocation.

It should be noted that in IPv6, the renumbering is a lot easier than in IPv4 and this was done very fast.

[7]

Now, on the allocation policy,

[8]

this is how unicast addresses are assigned. It’s based on RFC4291, and for the basic entities in the university (faculties) there’s a /60, for each backbone network, server farm or virtual machine bridge there’s a /64, and all the additional allocations are the same as the initial size (on request).
Also, allocations of separate /64 are available for special/specific projects.

[9]

The university also utilizes RFC4139 addresses, for local restricted resources. The allocations are done on /32 basis.

[10]

Now, onto the intra- and inter-AS routing,

[11]

The software used is Quagga on CentOS.
There is a specific reason for using CentOS – the distribution is a recompilation of RHEL, and follows it closely, which means that it’s as stable as it gets – if there’s a security or other important update, just the pieces are backported to the current version of the software, which effectively means that you can have automatic updates running on your servers and routers and be confident that they won’t break horribly.
That’s in stark contrast with almost every router vendor I can think of.

[12]

The current transit providers for the university network are Unicom-B (the academic network in Bulgaria), and SpectrumNet (now owned by Mobiltel).
The university has private peering with Digital systems, Evolink (it changed it’s name from Lirex), ITD, Netissat and Neterra. It also provides an AS112 stub node.

(For the people that don’t know, AS112 is somewhat volunteer project run anycast nodes for the DNS servers for some zones that generate crap traffic, e.g. “example.com”, or the reverse zones for the RFC1918 addresses)

[13]

This is the basic schema of the external connectivity. The university has two border router, each of which is connected to both upstream providers (and to the private peers, but that would’ve cluttered the drawing too much). They’re interconnected through one of the MAN networks, and are in the Lozenetz campus (where the University Computing Center is, the main operator of the network) and the Rectorate.

[14]

These are the prefixes that the university originates. Here we can see why the university has a /47 – so it could be de-aggregated, for traffic engineering of the inbound traffic. That’s one problem that nothing has solved yet, and that would plague us for a lot more years…
Here each border router announces a /48, and both announce the /47, so they can effectively split the inbound traffic.

There’s also the IPv6 prefix for AS112, announced from both borders.

[15]

This is what every router should do for the prefix announces it receives. Basically, everything from a private ASN is dropped, and all prefixes that are not in 2000::/3 (the unicast part of the IPv6 space), are shorter than /3 or longer than /49 are also dropped.

[16]

Here you can see the schema of the backbone network – the two border routers, and the access routers of the faculties. They’re all under the administrative control of the network operations team.

[17]

For this schema to work efficiently, the two border routers do the job of route reflectors, and the access routers are route reflector clients – e.g. each access router has two BGP sessions, one with each border router, and that way it learns all the routes coming from the rest of the access routers.
This setup would’ve been unmanageable otherwise, as doing a full mesh of so many routers would’ve resulted in full mess.
[Ok, I didn’t think of that pun at the presentation]

[back to 16]

The initial idea was to actually have the border routers be route reflectors only, and have all the access routers in the VLANs of the external BGP peers, for the traffic to flow directly and not have the two borders as bottlenecks. This wasn’t implemented because of administrative/layer8-9 issues.

[19]

This is how the core network connects with the faculty networks – the access router is connected in a network with the routers of the faculty, and via OSPF (or RIP in some cases) it redistributes a default route to them.

(Yes, RIP is used and as someone told me a few hours ago, if it’s stupid and it works, maybe it’s not that stupid)

[20]

Now here’s something I would’ve done differently :)

Both OSPF and RIP are secured using IPSec, here’s how the config looks like.

[21]

This is not something that you usually see, mostly because it’s harder to configure and the weirdness in the interoperability of different IPSec implementations. For an university network, where risk factors like students exist, this provides a layer of protection of the routing daemons (which, to be frank, aren’t the most secure software you can find) from random packets that can be sent in those segments.
It’s reasonable to accept that the kernel’s IPSec code is more secure than the security code of the routing daemons.

This the only thing that this setup provides more than the other options – a pre-shared key is used, as there aren’t any implementations that have IKEv1 and can be used for this task.

Also, this is harder to operate and configure for untrained personnel, but the team decided to go ahead with the extra security.

[22]

And of course, there has to be some filtering.

[23]

Here’s a schema of one external link – in this case, to Neterra.

[24]

Here we can see the configuration of the packet filtering. This is basically an implementation of BCP38.

First, let me ask, how many of you know what BCP38 is?
[about 25-30% of the audience raise their hands]
And how many of you do it in their own networks?
[Three times less people raise their hands]
OK, for the rest – please google BCP38, and deploy it :)
[Actually, this RFC has a whole site dedicated to it]

Basically, what BCP38 says is that you must not allow inbound traffic from source addresses that are not routed through that interface. In the Cisco world it’s known as RPF (Reverse path filtering), AFAIK in Juniper it’s the same.

In Linux, this is done best using the routing subsystem. Here what we can see is that on the external interface we block everything that’s coming from addresses in our network, and on the internal – anything that’s not from the prefixes we originate.

[25]

Here we can see the setup on an access router (as we can see, BCP38 is deployed on both the border and access routers). Here we can differentiate and allow only the network of the end-users.

[26]

On the border routers, there’s also some filtering with IPtables, to disallow anyone outside of the backbone network to connect to the BGP daemon, and also to disallow anyone to query the NTP server.
(what’s not seen here is that connection tracking is disabled for the rest of the traffic, not to overload it)

[27]

On the access routers, we also have the filtering for the BGP daemon and the NTP server, but also

[28]

we filter out any traffic that’s not related to a connection that was established from the outside. This is the usually cited “benefit” of NAT and the reason for some ill-informed people to ask for NAT in IPv6.

With this, the big-bad-internet can’t connect directly to the workstations, which, let’s be frank, is a very good idea, knowing how bad the workstation OS security is.

[29]

The relevant services provided by the university have IPv6 enabled.

[30]

Most of the web server have had support since 2007.

The DNS servers too, and there’s also a very interesting anycast implementation for the recursive resolvers that I’ll talk in detail about later.

The email services also have supported IPv6 since 2007, and they got their first spam message over IPv6 in on the 12th of December, 2007 (which should be some kind of record, I got mine two years ago, from a server in some space-related institute in Russia).

[31]

ftp.uni-sofia.bg has been IPv6 enabled since 2010, it’s a service for mirroring different projects (for example Debian).

The university also operates some OpenVPN concentrators, that are accessible over IPv6 and can provide IPv6 services.

[32]

The coverage of the deployment is very good – in the first year they had more than 50% of the workstations in the Lozenetz campus with IPv6 connectivity, and today more than 85% of the workstation in the whole university have IPv6 connectivity.
(the rest don’t have it because of two reasons – either they are too old to support it, or they are not turning it on because they had problems with it at the beginning and are refusing to use it)

Around 20% of the traffic that the university does is IPv6.
[question from the public – what is in that traffic? We should be showing people that there’s actually IPv6 content out there, like facebook and youtube]

From my understanding (the university doesn’t have a policy to snoop on the users’ traffic) this is either to google(youtube), or to the CERN grid (which is IPv6 only). Yes, there actually exists a lot of content over IPv6, netflix/hulu have already deployed it, and it’s just a few of the big sites (twitter is an example) that are still holding back.

The university provides both ways for the configuration of end-nodes – Router Advertisement (RA) and DHCPv6. For most cases they’re both needed, as RA can’t provide DNS servers, and DHCPv6 can’t provide a gateway (which is something that’s really annoying to most people doing deployments).

[33]

Here’s how the default route is propagated in the network.

[34]

This was actually a surprise for me – there are actually two default routes in IPv6. One is ::/0, which includes the whole address space, and there is 2000::/3, which includes only the unicast space. There is a use for sending just 2000::/3, to be able to fence devices/virtual machines from the internet, but to leave them access to local resources (so they can update after a security breach, for example).

[35]

Here is how you redistribute ::/0, by first creating a null route and adding it in the configuration.

[36]

And here’s how it’s propagated in the network, using OSPF.

[37]

We can do the same for 2000::/3,

[38]

and push it to the virtual machines, who also have connectivity to the local resources through a different path.

[39]

Now, this is something very interesting that was done to have a highly-available recursive DNS resolver for the whole network.

[40 and 41 are the same, sorry for the mistake]

[41]

This is how a node works. Basically, there’s a small program (“manager”) that checks every millisecond if the BIND daemon responds, and if it’s just starting, it adds the anycast resolver addresses to the loopback interface and redistributes a route through OSPF.

(note the addresses used – FEC0::.. – turns out that this is the default resolver for MS windows, so this was the easiest choice. Seems that even in the land of IPv6 we still get dictated by MS what to do)

[42]

If the name server daemon dies, the manager withdraws the addresses.

Also, if the whole nodes dies, the OSPF announce will be withdrawn with it.

[43][44][43][44][43][44]

Here you can see what changes when a node is active. If one node is down, the routers will see the route to the other one, and send traffic accordingly.

[45]

And if they’re both operational, the routers in both campuses get the routes to the node in the other campus with lower local preference, so if they route traffic just to their own, and this way the traffic is load-balanced.

[46]

Thank you, and before the questions, I just want to show you again

[3]

the people that made this deployment. They deserve the credit for it :)

[In the questions section, Stefan Dimitrov from SU stood up and explained that now they have three border routers, the third one is at the 4th kilometer campus]

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

(и определено можеше да е по-добре, не става добре да говоря на конференции, където имам занимания и с организацията)

Single points of failure

[за какво става въпрос]

Single point of failure е единичен компонент от система, при чиито отказ цялата система спира да работи.

В системите, които правим/ползваме и са повече от един сървър, на който ни е всичко (т.е. един гигантски SPOF) такива неща пак се срещат доста често.

[авиационен модел]

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

[авиационен модел 2]

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

Също така системите стават твърде усложнени, като пример – A380, който е наистина подсигурена система, има в себе си 530км кабели. Цената да се изгради и да се поддържа такава система не е по силите на някой друг.

[три неща]

И три неща, за които няма да говоря подробно.

[Софтуерни]

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

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

[Meatware]

Човешките SPOF-ове са още по-гадна работа. Известни са още като “Bus factor”, т.е. колко човека трябва да ги блъсне автобус, за да спре да работи даден проект (и в много случаи факторът е 1).

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

Метод за омекотяване е писането на документация, което па всички го мразят.

[цена]

Оценката кога си струва да се вложат средства, за да се избегне SPOF не винаги е тривиална и е за друг вид лекция. Има неща като risk assessment, гадаене по черва на гълъби, хвърляне на зарчета и статистически анализи, които се използват за целта, но много често и хората, които ги предлагат ги объркват…
(който се интересува от проблемите на анализа на риска, може да зачете Насим Талеб)

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

[state]

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

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

Искам да го повторя и да покажа, не съществуват stateless системи.

[примерна не-stateless система]

Ето един често срещан пример – смята се, че ако имаме такава схема, то web сървърите ни са stateless, понеже реално са взаимозаменяеми.

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

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

[решения]

Ето няколкото типа решения на проблема.

[do nothing]

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

[backup plan]

Може да не е толкова безсмислен като тоя от слайда :)
Тук решението е да знаем какво правим, ако нещо се счупи. За някои по-малко важни системи например backup plan-а може да е “машината е в гаранция, ако се счупи нещо, обаждаме се на тия от които сме я взели и така”, или “обаждаме се на другарче”.

[cold spare]

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

Това е и едно от най-често срещаните решения, понеже доста лесно се прави. От друга страна може да предизвика прилично количество donwtime, докато се “стопли” резервата.

(някъде тук на лекцията се оказа, че има хора, които не държат резервни крушки у тях…)

[hot spare]

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

Това много често се изполва в setup-и с бази данни или подобни неща, при които чистото дистрибутиране (за което ще говоря по-нататък) не може да стане заради CAP теоремата.
(ще намразите cap теоремата след малко)

Тук има един специфичен момент, т.нар. fencing – ако втората система поема работата на главната, трябва по някакъв начин да се гарантира, че главната е спряла и не прави нищо, за да не се стигне до омазване на shared state или нещо такова. За целта има няколко типа решения, някои от които просто спират тока на главната :)

[CAP теорема]

И така, преди да си говорим за най-хубавия начин – да имате N на брой машини, те да вършат едновременно работа и хем да се scale-вате, хем да сте защитени от сривове, да кажа защо това е непостижима мечта…

Теоремата е съвсем проста и гласи следното: една дистрибутирана система може да има най-много две от следните три свойства: Консистентна, винаги достъпна, издържаща разделение.

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

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

Издръжливостта на разделение значи, че не може да се достигне т.нар. split brain ситуация – ако системата се раздели на две части, не може двете да мажат в/у данните и да се получи при тях различна версия.

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

[дистрибутиране]

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

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

[load ballancers + web]

Това е един доста класически случай за повечето сайтове, на които не им се иска да имат downtime. Слагате отпред два load ballancer-а, които знаят кой от web сървърите отзад работи и балансират м/у тях заявките. Това работи много добре, сравнително стандартизирано е и сглабянето му не отнема особено много време. Достатъчно стандартно е, че amazon да предлагат компонентите му като някакъв service.

При отпадане на компоненти системата го усеща и спира да му подава трафик.

RAID масивите са доста близки като идея до това.

[синхронни бази]

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

[hack-ът за eventual consistency]

И има една добавка, като удобен hack при системи, при които има случаи, в които може да се прочетат стари данни, т.нар. eventual consistency.

В общи линии това представлява система, за която операциите за писане са приключили при запис в X компонента, като обикновено X=N/2 + 1. Тогава имаме inconstent четене, което може да чете от 1 компонент, и ако ни трябва консистентно, четем от N-X+1 компонента. Това се използва основно за системи, при които консистетният read е рядка операция.

[sharding + replication]

Това е текущият метод за репликиране на база данни. В общи линии умножавате факторите за на колко искате да разделите данните (за performance) и за redundancy и получавате колко железа ви трябват (в случая са 2X2).

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

Миналата седмица направих workshop на тема как правим записите по конференциите (който беше доста успешен), ще го повторя тази неделя от 13:00 в initlab (преди git събитието). Повечето неща са казани във wiki-то на va.ludost.net, но си е друго да се пробва на живо.
(щеше да е в събота, но тя се оказа работен ден)

Това ми е в общи линии lightning talk-а от Rails girls, май беше най-скучния.

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

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

Намерете си правилната перспектива, от там нататъка всичките ви притесненения стават дребни и решими.

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

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

Един друг хубав момент е, че точно това влиза в категорията “it gets better” – всеки път, в който преборим страховете си и постигнем нещо, прави следващия малко по-лесен, докато накрая притеснението остане като едно много дребно напомняне, че се хващаме да решаваме нещо по-сериозно.

Накратко – няма страшно :)

Може да се гледа в тубата, или да си го свалите. Текстът го има тук.

Има вече запис от втората ни лекция, може да се свали от va.ludost.net/files/20121104depression.mp4, hades.erihon.com или да се види в тубата. Презентацията може да си свалите в odp или pdf.

Откриването, където си говорим с Кънев може да се гледа тук.

Препоръчвам също така да гледате depression panel-а от 28C3, който беше големият тласък изобщо да направим тая лекция.

Текстът ще отнеме малко повече време да се появи.

До тук имаше много положителен feedback, включително от един професионалист (което в общи линии made my day), много хора ми писаха, за да кажат, че и те са имали/имат проблем и в общи линии има и желаещи да слушат другите: Стефан Кънев, iffi, Нейчо Михов, аз и Яна. Още работя по идеята как да го организирам това, надявам се скоро да пиша нещо.

Преди това обаче имам да наваксам с работата, че някои неща взеха да се трупат (не-админски дейности).

Update: И Комитата е в групата на слушащите (аз бях говорил с него на феста и бях забравил, та той ми напомни на ТББ снощи).

Ето текста на презентацията ми от Openfest 2012 за това как 700 сървъра се поддържат по-лесно от 3. Оставил съм бележка на кой слайд съм, понеже има няколко полезни картинки из презентацията (pdf, odp).

Update: видео запис.

[слайд 2]
Занимавам се със сървъри в общи линии от малък и винаги ми е било интересно. След като в последните 3 години се занимавах с една голяма система (около 750 машини, 7.5PB място, 260gbps трафик в разни моменти) открих как големите системи са по-лесни за поддръжка, понеже ни карат да правим нещата по правилния начин (иначе просто няма да се справим).
Също така искам да отбележа, че аз съм адски мързелив и не много умен (за последното даже имам издаден документ от МЕНСА) и намирам това за лесно, т.е. според мен всеки, който реши може да се справи:)

[слайд 3]
Това е снимка от едно от първите неща, с които съм се занимавал (за съжаление нямам снимка на първия си сървър, как стоеше до един шкаф с 6-7 модема и това си беше цялата система). Да сравним с

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

[слайд 5]

Малко бележки, преди да започна – аз различавам три типа “операции”.

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

Вторият вид са големите, “enterprise” операции – като пример мога да дам телекомите (които за мен са много повече неприятен начин на мислене, отколкото нещо друго) – това са компании, които разработват и изобщо разбират частично технологията си и основно плащат на външни фирми много пари, които после да могат да поемат вината за проблемите, и да реагират в някакво време (например 2-4 часа) за да оправят счупеното.

Третият вид са тези, за които ще говоря, и които по принцип наричам “порно компании”, поради това, че повечето от по-големите фирми, които се занимават да сервират и т.н. порно по интернет са такива (но и twitter, reddit, github също си приличат с тях). Това са операции, които сами поддържат почти цялата си инфраструктура и продукти, които използват почти ексклузивно open-source софтуер, дописват го за собствени цели и успяват с бюджет, който е с един-два пъти по-малък порядък от enterprise хората да постигнат толкова или повече.

(има четвърти тип, който пропуснах на лекцията, гигантите като facebook и google, от които идват някои от идеите по-долу).

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

[слайд 6]

Големите системи ни принуждават да научим някои неща, без които никога няма да можем да се справим с натоварването. Разширяването на системите е много по-лесно от разширяването на персонала и доста по-ясно като задача, та ако не се работи правилно, много често админите на някаква система издъхват, преди да е стигнала някакви сериозни размери. Изброил съм доста от полезните уроци, които са ми улеснили много работата – повечето ги има в хубавите книги.
Изобщо, ако ви е интересна темата, идете и прочетете “The practice of system and network administration”. Ще откриете много интересни работи…

[слайд 7]

Да започнем с мониторинга. Лафът “има два типа хора, такива на които им е гърмял хард диск и такива, на които ще им гръмне” ми е толкова любим, че чак го написах в презентацията …
Поддръжката на система без monitoring е подобна на шофирането сляп и глух. Няма да имате идея какво правите, какво се случва и какво го предизвиква и в общи линии ще трябва да гадаете.
Имам една примерна случка от съвсем наскоро – един приятел има лична машина, co-locate-ната някъде, на която има два RAID1 масива с по два диска. Преди около година един диск от единия масив отказал, след това преди 3-4 месеца отказал още един диск, но от другия масив. По някое време един негов приятел минавал през colocation-а и после му казал “абе ти знаеш ли, че на твоята машина отпред светят две червени лампички?” (някъде тук моя приятел твърдеше, че colocation support-а е трябвало да му каже, че има такова нещо, но те няма откъде да знаят това дали е нормално или не, няма стандарт за нотификация от предните панели). Та, тръгнал той да сменя дисковете, но докато се накани му гръмнал още един диск, а докато backup-вал – и последния.
Както би казал Captain Hindsight в такъв случай – “трябвало е да има monitoring и това нямаше да се случи”.

Monitoring-а ви пази от downtime – ще видите гръмналия диск преди да стане бедствие, пълнещата се файлова система преди базата ви данни да спре да може да изпълнява заявки или mail server-а ви да може да приема поща, ще ви каже, че някой service ви е спрял и какво ли не още.
Също така monitoring-ът ще ви даде данни за бъдещо планиране – колко трафик правите, с каква скорост си запълвате ресурсите, в кои периоди може да очаквате повече или по-малко натоварване, и т.н., и т.н..

Аз лично ползвам nagios за всичките си машини, включително и за някои неща по работната ми станция вкъщи.

[слайд 8]

Тук съм показал как изглежда моя системен статус – това е nagios checker, plugin за firefox, който показва постоянно статуса на един или няколко nagios-а (това е редчето най-най-долу) и при on-mouse-over показва по-подробен статус (всичко останало, което се вижда в жълто/червено). На този се вижда как два от ftp сървърите са малко по-натоварени, има 4 дискови масива, които се rebuild-ват, два масива дето са изхвърлили по един диск, един масив, който си мисли по въпроса и един IPMI модул, който изглежда е изгорял.
Има варианти на plugin-а и директно за gnome или каквато работна среда ползвате, всеки както му е удобно. Много хора ползват външен монитор или нещо такова да им стои там целия статус.

[слайд 9]

Може да видите няколко публични примерни monitoring-а – моят публичен nagios, един munin пак за същите машини (страхотен tool, лесен за конфигуриране, прави много добри графики и писането на plugin-и е направо радост за душата), и един пример за великолепно подкаран nagios с много услуги. Моят например има по 7-8 услуги за машина, които се следят, те имат по 20-30 и все подходящо измислени, препоръчвам на всеки да погледне какво и как следят.

[слайд 10]

Това е нещо старо като света, даже го намерих в една книга за писане на бази данни от 1992ра. Идеята е, че за една система не трябва да се налага да се променят няколко различни места, когато се прави промяна по нея – не трябва да се пипнат конфигурациите на 8-9 различни неща и да се направят други 10 действия, понеже хората грешат, ние сме хора и ще сбъркаме нещо. Или ще пропуснем определено действие, или ще объркаме нещо, докато го правим, а ако направим скрипт, който от една централна конфигурация да създаде всичките тия конфигурации и направи действията, първо ще си спестим работа, второ ще си спестим грешки. Скриптовете определено грешат по-рядко от хората…
Този съвет за съжаление рядко е използваем в малки системи.

[слайд 11]

Тук съм дал един мой примерен скрипт, който генерира конфигурация на dhcp сървър. Скриптът е грозен до смърт и съдържа в себе си три езика – bash script, SQL и dhcp config – но съвсем накратко прави следното: генерира един конфигурационен файл, тества дали е различен от текущия, ако да – пробва да рестартира с него, и ако не сработи, ми праща mail и връща старата конфигурация. Елементарно е да се напише, работи като слънце и не ме кара да правя много неща – този скрипт и още няколко се изпълняват от cron-а и всичко се update-ва без никаква човешка намеса.

[слайд 12]

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

[слайд 13]

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

По принцип началната инсталация е мястото с най-много грешки. Във всеки един инсталатор има м/у 20 и 100 избора, които трябва да се направят, особено ако става въпрос за сървър и потенциалът за грешка или просто различна инсталация е огромен. Вероятно няма начин един човек да направи 10 инсталации през debian-ския инсталатор за една седмица и да направи 10те машини еднакви (има шанс и 10те да са съвсем различни). Да си оставяте такава дейност е като да си пречите сами.
(за съжаление и това е безсмислено за по-малки системи, ако имате един сървър, няма от кой да е различен)

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

При мен инсталацията представлява следното: първо ми монтират машините в rack-овете и ги настройват да boot-нат по мрежа. Машините тръгват, зареждат през pxe/nfs един image, в който тръгва нормална операционна система, на която последният и boot script (/etc/conf.d/local.start, понеже е gentoo) стартира един мой скрипт, който от своя страна се свързва с една централна машина и казва “здрасти, аз съм с mac адрес еди-кой-си”. Централната система проверява този mac адрес на кой switch/port се намира, проверява в таблицата със сървърите (вижте на слайд 12) какво трябва да има там, дали е работещо или не и или казва “не прави нищо, не знам за тая машина/вече е инсталирана”, или дава нужните настройки като hostname, ip, net, gw. Ако има получени настройки, скриптът създава partition-и, прави файлови системи, настройва разни полезни неща като адреси на ipmi контролера и парола за него, разархивира един готов image, сменя по файловата система настройките като за машината, рапортува на централната система, че е готов и рестартира. Централната система си отбелязва, че машината е готова и че трябва да и даде да boot-не нещо друго на следващия път.
След което аз на сутринта си пускам лаптопа и виждам – а, имам още 18 инсталирани машини, хайде да им качвам съдържание (което също се прави с една-две команди). Мисля си, че единственият по-мързелив начин щеше да е да ми ги пращат готови инсталирани.

[слайд 14]
Тук малко ще се отклоня и ще се опитам да обясня колко важна е автоматизацията. Системните администратори сме мързеливи и ТРЯБВА да бъдем – хората, които не ги мързи ще си кажат “защо да автоматизирам това просто нещо, ще ми се налага да го правя само веднъж седмично/веднъж на ден” и в един момент се натрупват достатъчно такива дреболии, че не им остава време да се огледат и се получава “death by a thousand cuts”. Мързелът е важен, и може да видите на

[слайд 16]
програмист, който тренира за системен администратор.

[обратно на слайд 14]

Всичко, което се прави често, трябва да се автоматизира. Всичко, което се повтаря и се прави рядко – също, защото има шанс между две правения да забравим как става. Научете се да пишете код и пишете, това ще ви спаси живота. Няма нужда даже да е добре, ето един мой пример:

[слайд 15]

Това е един много прост скрипт, който проверява кои машини са report-нали, че имат проблеми с дисковите масиви, логва се да види какво се случва и ми вади списък в следния вид:

rack/cage (SD id)               server  port    serial
XXX/DA3:20460 (CUST.YYY)        s333    p9      JPW9H0HQ2XS8AH
XXX/DA3:20460 (CUST.YYY)        s452    p5      JPW9J0HD1J3JMC
XXX/DA3:20460 (CUST.YYY)        s542    p3      JPW9N0HZ0MN8JL

Това аз мога да го пратя на човека през океана, който да иде на място и да ги смени. Не съм направил скрипта и да праща поща, понеже има няколко случая, в които и аз трябва да погледна, преди да съм сигурен, че дисковете може да се извадят спокойно.
(някой ме беше попитал защо там има ssh root и т.н. – първо аз ползвам ssh agent и няма как някой, който се добере до машината да добие лесно достъп до всичките, и второ аз работя само от root – аз admin-ствам тези машини и почти няма команда, която да може да работи от нормален потребител, а да пиша sudo на всеки ред е безсмислено).

[слайд 17]

И една леко религиозна тема – трябва ви хубав naming convention. Това е от нещата, за които просто няма друг начин при големи системи. По принцип важното е имената да са лесни за произнасяне и запомняне (доста хора използват филми/сериали като източник (Simpsons), други използват фентъзи книги (в Толкин има около 200-300 героя, в Малазанска книга на мъртвите – около 1000)). Аз лично за тази система използвам съвсем простата конвенция от една буква, определяща функцията на машината (w – web server, d – db server, s – storage) и номер. Така знам машината какво прави само по името и е съвсем лесно да я кажа на човека отсреща, който се намира в шумния datacenter и около него вият 10-15000 вентилатора.
(от друга страна, личните ми машини имат съвсем random имена, щото са малко и защото успявам да ги запомня – marla, tyler, cassie, lain, alpha…)

[слайд 18]

Резервните пътища са нещо също много важно. Почти всеки, който някога е администрирал каквото и да е отдалечено си е отрязвал клона, на който седи (в слайда има прекрасен пример с ifconfig eth0 down).

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

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

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

[слайд 19]

Може би понеже аз съм тръгнал от интернет доставчик ми е странна идеята някой друг да ми оперира мрежата, но това се оказва стандарта в момента – хората си наемат/слагат машини в някой datacenter, от datacenter-а им дават internet и мрежа през един порт на всяка машина и така цялата комуникация между компонентите на една система става 1) през порта, който е и за външния трафик и се бори с него и 2) през мрежа на някой друг, с различни цели и съответно такава, на която не може да се вярва. Мрежата е централен компонент на всяка една система в наши дни и невъзможността да знаете какво се случва в нея и невъзможността да го променяте/контролирате ви ограничава сериозно.
(например моята автоматична инсталация нямаше да има начин да става толкова лесно, ако не си контролирах мрежата)

Една фирма, с която работих преди известно време имаше огромен проблем с това, че не си контролираше мрежата – те са по-големи от това, с което се занимавам (имат около 1800 машини в 4-5 големи datacenter-а) и съответно понеже им се налагаше да репликират mysql през internet, бяха правили някакви страшни и почти гениални изпълнение, за да им работят нещата, а докато бях при тях, основните проблеми идваха от мрежата.

Също така собствената мрежа ви дава възможност да пуснете BGP, да си вземете ASN и за всякакви такива други хубави трибуквени съкращения :) Така може да купувате свързаност от няколко различни доставчика и да не трябва да им търпите проблемите.
Ще говоря накрая и за една много хубава моя система за наблюдение на трафика, която пак щеше да е невъзможна без моя мрежа.

[слайд 20]

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

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

Препоръчвам на всички да тестват следното – да се напият, да си си легнат към 12 и да са си навили алармата за 4 сутринта, след което да станат и да се опитат да направят нещо просто (например да решат квадратно уравнение или някой прост тест за интелигентност). Вероятно ще има отрезвяващ ефект :)

Нека да цитирам Jim Gray, “Although there are no textbooks on simplicity, simple systems work and complex don’t.”. Това всички го виждат, но никой не иска да го приеме, понеже изглежда простите системи не са готини, и човек не изглежда умен, ако не направи нещо гигантско и сложно (което после се оказва невъзможно за поддръжка). Както при програмирането дебъгването е три пъти по-сложно от писането, така при правенето на системи работата с тях и оправянето на проблеми е доста по-сложно от измислянето и поне според мен хората, които правят много сложни и “умни” системи не са особено умни.

[слайд 21]

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

Първият е разпределението на натоварванията и събитията. Нека да дам за пример пасивния ми monitoring – той представлява cron скрипт, който веднъж на 5 минути се стартира и праща малко данни към един централен демон, който обработва информацията. Това при достатъчно сървъри би довело до претоварване на централната система и решението е съвсем просто – един sleep за random секунди (м/у 1 и 60), така че събитията да са пръснати във времето.

Другият е премахването на SPOF (single points of failure). Много често като наследство от времената, в които дадена система е била малка се намират разни компоненти, които ако откажат и цялата система спира да работи. В голяма система това трябва да се избягва и като цяло компонентите да могат да се заместват един-друг или да не са толкова важни, понеже колкото повече отделни части имате, толкова по-голям е шанса някоя от тях да откаже. Ако всяка част ви е жизненоважна, то ще трябва през цялото време да тичате след всеки дребен проблем и да нямате време да свършите нещо реално полезно.
Да се направи нещо дистрибутирано е сложна задача – стъпката от една до две машини (или даже от single thread до няколко thread-а) е тежка и по-сложна от тази от две до хиляда, но определено си струва. Ще ви спести будения посред нощите от големи проблеми и ще ви даде допълнително спокойствие.
(например аз почти нямам компоненти, които могат да убият цялата система със срива си, съответно мога да спя спокойно и каквото и да стане, да мога да го оправя на сутринта, като стана)

[слайд 21]

Ето един пример защо е важно да сме дублирани и да не зависим от отделни дребни неща – понеже редките явления в достатъчно голяма система стават нещо нормално. Този screenshot показва как на машина с 12 диска и 12те са гръмнали в един и същи момент.

Това ми се е случвало два пъти.
(първия път сърцето ми прескочи един път:) )

[слайд 22]

Две интересни неща, от големите системи и от при мен по принцип.

Едното е нещо, което много хора според мен не правят правилно. Много често се казва – имаме нов проект, айде да купим още web, db и т.н. сървъри и да направим отделна инфраструктура, вместо просто да се разшири текущата. Така човек се озовава с много малки компонентчета, от които който и да е ако замине, има някакъв downtime на някаква услуга и съответно пожари за гасене. Разширяването на текущите системи, и дистрибутирането (доколкото е възможно) всичко да може да работи от всяка машина дава огромно scalability, издръжливост на атаки и доста по-спокоен сън. Аз лично трябва да гледам внимателно дали някой ни DoS-ва, понеже при нас нещата са достатъчно добре разпределени, че почти да няма кой да ни засили ефективна атака.
Според мен и така трябва да се борят DoS атаките.

Другото хубаво нещо, което написахме и което исках да пусна да се ползва публично, беше система за следене на трафика и загубата на пакети. При нас ползваме web сървър, който е вътрешно производство, и той праща по един пакет статистика за всеки connection, който е завършил, с данни колко байта и пакета са минали, към кой ip адрес, за колко време, тип на трафика и колко TCP retransmit-а е имало. На база на тази статистика и BGP таблицата аз мога да видя почасово към кои мрежи и автономни системи (и през кои пътища) имам повече загуби и да преценя дали искам да изместя част от трафика някъде другаде.
(след конференцията един приятел се нави да port-не нещото за apache и да пуснем колкото можем от него open-source, та може да има новини по темата скоро)

[слайд 24]

Та, ако ви е TL;DR лекцията, какво си струва да запомните:
1) имайте (добър) monitoring
2) правете нещата толкова просто, че да може да ги ремонтирате в 4 сутринта на пияна глава
3) Автоматизирайте
4) Имайте резервни варианти

(и пращайте корекции на тоя текст, че е писан на един път)

Свърши Openfest 2012, и въпреки че не бях в организацията пак съм скапан.
(дължи се на работа и участие в 4-5 лекции (2 мои))

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

И двете лекции се получиха доста добре, въпреки че втората не успяхме да я репетираме изобщо (и я дописвахме в неделя на обяд). Ето презентацията от първата (odp,pdf) и втората (odp, pdf). Мисля да помоля организаторите да ми дадат записа на втората да го пусна по-рано.

Специално за втората аз и Яна си бяхме дали адресите накрая, за хора, които имат нужда да си говорят с някой (vasil(at)ludost.net, yana(at)ludost.net), също така се включи и Нейчо Михов (neycho.mihov(at)gmail.com), ще добавя в тоя post (и като измисля някакъв сайт за целта – и там) адресите на всички останали желаещи да слушат другите.
Може би най-хубавото и неочаквано нещо беше колко много хора след това ми благодариха, казаха колко е била хубава лекцията и казаха, че сериозно са се замислили. Искам да благодаря на всички от “програмния комитет”, които бяха на моя страна за правенето на тая лекция, и най-вече на Стефан Кънев.

Също така мисля, че този openfest затвърди традицията аз и Стефан Кънев да се ебаваме един с друг. Той ми провежда “интервюта” и в предишните си презентации намираше къде да ме добави (в последната ме нямаше), а след историята със снимането обяви, че ако с мен се снимат 50 човека, ще направи продължение на intro клипчето от openfest.
(историята със снимането е как като бях отишъл на една лекция от курса по Python и си говорех с него в почивката дойдоха при нас няколко студента, той ги пита какво искат да питат и те му казаха – нищо не искаме да питаме, искаме да се снимаме с крокодила… Кънев много обича да я разказва тая история…)
След като с мен се снимаха много хора, аз в последния slide на лекцията за депресията сложих една снимка на Кънев, допипната от Лъчко, на която да изглежда депресиран и приканих хората да се снимат с него, за да го ощастливят. Погледнете, мисля, че Лъчко страхотно се е справил :)

В крайна сметка обаче той води – с мен се снимаха толкова хора, че в един момент ми беше трудно да гледам от всичките светкавици. Чудя се как да му организирам flash mob.

(а колко хубаво си допихме и куфяхме на afterparty-то, думи не могат да опишат, та оставям на някой друг да разкаже :) )

Update: iffi също се включи в списъка на слушащите.
Update 2: Стефан Кънев също се включи в списъка на слушащите.

Идва OpenFest 2012, ще правя там две лекции.

Едната ще е за това колко по-лесно се поддържат 700 сървъра, отколкото 3 – според разни хора това би било интересно (за мен голяма част от нещата са твърде стандартни и ги пише по всичките книги). В последните 2-3 години насъбрах много забавен опит около това и се надявам да не се получи много скучно. Ще бъде от 17:00 в събота в зала София.

Другата ще е по любимата ми в последната една година тема за депресията, самоубийствата, проблемите в главата и други такива весели неща. Отдавна мисля, че е нужна подобна лекция – проблемът е голям в цялото IT общество, но всички се опитват да не го забелязват (при това доста успешно). Ще я водя заедно с Яна Петрова. Ще бъде в неделя в галерията от 14:00.
(имаше сериозен вой и отпор против лекцията, но и доста хора, които се заинтересуваха и бяха за)

Иначе, има още няколко интересни неща. Едното е лекцията на Венета Донова за юридическите моменти около поддържането на сайт и предлагане на услуги през него, от 12:00 в събота в зала София (за която поемам част от вината, аз я навих да я прави), другото е лекцията на Владо Василев за hackerspaces на балканите, в България и какво се случва в последната една година, от 15:20 в събота в галерията(където имам някакво минимално участие и третата (с която нямам нищо общо) е лекцията на Стефан Кънев за парадигмите в програмирането, от 11:15 в събота в зала София (поставя си много висока цел с тая лекция, да видим как ще се справи :) ).

(а мен ме чака още доста писане и редактиране, особено за втората ми лекция)

Спимисеспимисеспимисе.

(преди всичко – браво на dzver-а, че въпреки всички идиотски пречки и т.н. се справи с wordcamp-а, без да се налага после да го прибираме в някоя лудница, браво и на Ники Бачийски).

Днес беше WordCamp Sofia 2012.

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

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

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

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

Afterparty-то беше интересно, в някакъв странен бар (май се казваше “Dada”), където се засякох с всякакви стари познати, пийнахме добре и даже по едно време Марио посвири на пианото. Аз успях да сбъркам пак Калин и Ниньо (и да помисля Калин за Радо), смятам сериозно да проуча как точно тия тримата са се събрали в лаба и защо са ми толкова подобни. Само се притеснявам, че ще взема да изкарам наяве някаква история от техните родове, дето никой не я знае…

Имаше и въпроси по темата дали с Кънев живеем заедно (не) и дали имаме някаква връзка (не, въпреки че му се иска). Вероятно трябва да се напише FAQ по въпроса.
(примерни въпрос/отговор:
Q: Защо Стефан прави палачинки сутринта през weekend-ите?
A: Защото знае, че е любимата храна на крокодила и го подмамва с подли намерения.
)

Откривам, че паметта ми никаква я няма и вероятно трябва да намаля малко четенето и прекъсванията. Очаквайте записи от wordcamp тия дни.

Мина втората книжна лекция. Бях уморен, говорих зле и доста “значи”. В общи линии препоръчвам да видите книгите въпреки некадърния начин, по който съм говорил/писал за тях. Блокирал съм и се надявам да се оправя за седмица две (ако трябва, ще се напия лошо, да направя hard reset).

Запис.

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

Cryptonomicon на Neal Stephenson

“Историческа фантастика” – история, която включва хора като Алан Тюринг, Дългас Макартър, Чърчил и други интeресни исторически фигури, обсъждайки през цялото време криптографията, приложенията и, data heaven-ите и други близки теми. Много добре написана, книгата е една от най-известните такива в компютърджийските среди.

Barefoot into cyberspace на Becky Hogge (може да се чете/свали на сайта ѝ).

Описание на историята от последните няколко години в “киберпространството”.Описва CCC конгреса, срещите си с Rop Gonggrijp и Julian Assange, Cory Doctorow и може да представи доста от събитията от тогава в перспектива.

Coders at work

Интервюта с различни програмисти – как работят, какво са правили, и т.н.. Включва:
Доналд Кнут
Кен Томпсън
Питър Норвиг
Jamie Zawinski
Полезно е да се види как работят хората, чиито софтуер по един или друг начин ползваме. Кънев ме помоли да отбележа как никой от тях не ползва debugger и debug-ват с print.

Where the wizards stay up late на Katie Hafner и Mathew Lyon

История на създаването на Internet. Обхваща нещата от първата разработка на IMP-овете за ARPAnet до нещата, които ползваме в наши дни. Има доста подробности, но нивото е достатъчно ниско, за да може да се разбере от повечето хора.

TCP/IP Illustrated Vol.1 на W. Richard Stevens

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

The practice of system and network administration на Thomas Limonicelli и Christine Hogan.

КнигаТА за системна и мрежова администрация. В нея няма команди и обяснения как да пуснете нещо съвсем конкретно, но реално има почти всичко, свързано със системната и мрежова администрация, от базови принципи за правене на системи, през различни типове услуги, до глави като “Being Happy” и “Firing System Administrators” (което е от нещата, които много хора не знаят). Трябва просто един път да погледнете съдържанието :) Книгата е на достъпен език и може да бъде четена спокойно от не-технически хора.

Little brother на Cory Doctorow, достъпна под свободен лиценз, например тук.

Донякъде антиутопия – описва свят, в който след още един атентат американците тотално се побъркват и въвеждат средно-тоталитарни мерки в един град. Разказът е за група тинейжъри, които се борят срещу това чрез различни технологии. Добър увод за някои технологии като rfid, криптография с публични ключове и mesh мрежи.

Gang leader for a day на Sudhir Venkatesh

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

V for Vendetta на Alan Moore, илюстрирано от David Lloyd

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

Yokohama Kaidashi Kikou на Hitoshi Ashinano.

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

И като bonus – “То” на Стивън Кинг. Не я четете преди лягане, но я прочетете – голяма и интересна история, влиза ви под кожата и ако не друг, може да ви покаже как се пише наистина добре.

Update: Оказва се, че TCP/IP Illustrated vol.1 имала второ издание, с допълнения – нещо, за което говорих, че ми се иска да стане. Изглежда прилично на пръв поглед, като я прочета, ще пиша пак.

Update: Лекцията ще се проведе на 4 октомври 2012 в initLab от 20:00.

Планирам да направя втора книжна лекция, пак в initLab. Възможните теми са:

1) компютърно-исторически книги
2) твърда фантастика, чиито идеи ще имат/имат отражение в компютърджийството
3) класически технически книги
4) “главознание”
5) смесица от каквото ми падне

Предпочитания?

(лекцията мисля да е на края на тая седмица (неделя) или следващата (вторник/четвъртък)).

Докато си вися на Aniventure, малък status update:

Лекции записваме всякакви. Последно беше crash course в django, още записваме лекциите на курса по микроелектроника (които успяват да направят по една non-stop лекция от 19:30 до 23:00 без някой да припадне) и се появяват всякакви нови идеи, от които вероятно ще се реализират 10% и ще пак ще се запълни времето на лаба.
(всъщност, всякакви интересни идеи за лаба се приемат, мисля, че си го пише на сайта :) )

Аз имам идеи за две лекции – едната е как става поддръжката на 700-800 машини (системата в hotfile), за която вече имам фирменото съгласие, другата е депресията, самоубийствата и другите такива весели неща (за която все повече и повече говоря в последно време, наскоро на един рожден ден се напих и говорих около 3-4 часа по темата). Не е ясно дали ще мога да реализирам и двете (за втората още не съм сигурен, че искам да се захвана, на първата съм готов на 30-40%).

Също така, търся някой да помогне с малко javascript, да направим нещата на va.ludost.net гледаеми през някой flash player – самите файлове нямат проблем, модула за seek-ване ще го добавя в web сървъра тия дни, само някой трябва да направи свързващия момент. Ако се намира желаещ, да се обади, ще седнем някой ден в лаба и ще попишем :)