Прво, следи упозорење. Не покушавајте ово код куће, на свом коду.
Иако у пракси наших програмера и бекап има свој бекап, а иза њега још један бекап, софтвер развијају људи, а сви знамо колико је људски грешити. Наши сјајни момци поделили су своје грешке, мало се смејући мало уздишући, у једном искреном разговору који се повремено, готово са терапијским дејством и уз мало пице и пива, одржава под називом Инфостуд Тецх Талкс. Овог пута, друштванце се окупило онлине, али приче би се могле свести под један наслов – највећи факап моје каријере.
Док се атмосфера захуктавала, један по један су отварали душу, говорећи о грешкама које су се дешавале и најискуснијим девелоперима. Некима првог радног дана. Другима на месту шефа ИТ-ја. Некима због неискуства, најсрчанијима у жељи да промене систем. Гасили су се сајтови, брисале базе података, продукције су падале као снопље, али једно је важно – све то је унапредило и систем, и људе.
И зато, изабрали смо топ три грешке које су биле тааако велике, да је било хватања за главу у нашем малом прогамерском кружоку, неверице и подсећања на одсецање ногу и по неколико бесаних ноћи и дана док се све то пеглало. И испеглало се, срећом, баш све. Погађате зашто? Углавном зато што су колеге биле ок, што је шеф имао разумевања и што је онај ко је погрешио из тога научио озбиљну лекцију.
Бронзани факап – ИТ тим сајта 4зида.рс
Капетан брода који тоне
Постоје грешке које се десе као последица непажње или недостатка безбедносних механизама, бекапа итд. Али, ево једне приче која није имала везе са тим. Понекад се грешке једноставно крију у предрасудама, у начину размишљања. Елем, почели смо да користимо MongoDB, чији сам био један од великих фанбојева, а једна од ствари које је могао да чува је да у склопу документа стоје бинарни подаци. Пошто смо ми стално кубурили са пермисијама око слика, (ко год је радио са сисадминима, знаће о чему причам), пало ми је на памет да снимимо слике директно у оглас. Постојало је ограничење од неких 16 мб, а како сам анализирао ни једна колекција нам није то прелазила, јер то је било пре и камере су биле слабије. У теорији то би радило. Урадио сам истраживање, причао са сисадминима шта мисле о томе, са колегама, гуглао… Нико то није радио пре, али није било ни неких јаких савета против. И онда смо једне среде решили да то пустимо. Све слике су почеле да се снимају у сам оглас, а не на диск. Али, наши огласи се импортују периодично и та промена није одједном захватила све огласе, него је полако ишао крон и пребацивао.
У том тренутку сам се осећао као капетан који стоји и гледа брод како тоне. Та количина бинарних података је успорила претрагу, апдејтове, инсертове, све! И тако гледаш како сајт који се учитавао за 2 секунде како учитава претрагу три минута. И ништа се није поломило, ништа није изгорело, сајт није био офлине, једноставно је био спор до непрепознатљивости. Прво нам је требало времена да сконтамо шта се ту дешава, али то је била једина велика измена коју смо радили. И онда је само била ствар живаца ишчекати два сата колико је требало да се те слике врате назад, све гледајући како се сајт вуче као неки крш. Ни дан данас ја не знам како бих то могао симулирати, тестирати, на тој посети и броју огласа као што смо имали тада, осим на тај начин. И није ми жао што сам покушао.
Сребрни факап– ИТ тим сајта Половни аутомобили
Ако колега поред вас хипервентилира, мора да је гадан query
Која је прва реакција програмера на факап? Колега је почео да хипервентилира, навукао је капуљачу и спустио главу на сто. Обратио сам пажњу на његов монитор и видео да је извршио један врло дестуктиван qуерy. Видео сам да нешто морамо да урадимо. Зауставили смо сајт, ставили га офлајн, јер је query анулирао датуме свих огласа на сајту. Сисадмини су имали бекап, али потребно је довући све, извући податке из табела, написати скрипту да те податке које смо обрисали вратимо назад у табелу и то уопште није једноставан процес. Колега Данијел је имао сјајну идеју, написао је query који је реконструисао датуме постављања огласа на основу датума њиховог првог прегледа.
Финална последица била је 45 минута офлајн сајта Половни аутомобили, који има 750 000 посета дневно. Тада су нам сисадмини на развојном алату који се користи на продукционој верзији, убацили црно-жуто упозорење РАДИТЕ НА ЛАЈВУ, како бисмо стално били свесни где се налазимо. Увек постоји вероватноћа да уколико програмер не пази да се такве ствари десе и сутра. Наравоученије: пазимо у ком окружењу радимо, да ли је тестно или је лајв и не пуштамо ствари петком и пред крај радног времена.
Златни факап – ИТ тим сајта Послови.Инфостуд
Нови сервер шаље рандом мејлове кандидатима
Било је то почетком 2013. Те године радили смо на потпуном преписивању сајта Послови.Инфостуд. Као сви добри девелопери, желели смо са новим сајтом да имамо гланц нови custom-made state-of-the-art queue систем за одложено слање трансакционих мејлова, са аутоматским архивирањем. У исто време наше колеге из системске администрације планирале су да изведу дуго најављивану промену MySQL engine-a sa MyISAM na InnoDB.
Десетак минута након пуштања сајта, јавља нам се корисник и тврди да је у мејлу за заборављену шифру, добио и биографију непознатог корисника. Идеју да је наш нови систем проузроковао ову грешку, технички смо одбацили у моменту и приписали грешки корисника. Али Инфостуд је годинама и пре тога давао апсолутни приоритет ситуацијама у којима постоји могућност да лични подаци наших корисника процуре трећим лицима. Треба имати у виду да је ово шест година пре ГДПР-а и да је чак и у недостатку правне регулативе ово схваћено као проблем, а имало је потенцијал да се претвори у озбиљну кризу. И само због тога, одлучили смо да сајт ставимо ван функције, док не утврдимо како и зашто је дошло до овога и пре свега, да ли је нова апликација Послова одговорна за то. Ово је иначе и време када се у Инфостуду појавила потреба за кризним ПР-ом. ?
ИТ сектор је био слуђен. Сатима нисмо могли да објаснимо како се ово десило. У исто време, приступили смо анализи логова, да бисмо утврдили колико корисника је оштећено, колико њих је дошло у посед туђих информација, и тачно, чији лични подаци су “процурели”. Телефонски смо контактирали сваког понаособ. И имали смо срећу да су сви веома лепо реаговали на нашу отвореност.
Сајт је стављен у функцију тек након што смо технички утврдили шта се заиста десило. Након бесомучног гуглања, утврдили смо да је преласком на нови MySQL engine, промењена једна од кључних функционалности тзв аутоинцремент поља, која се код InnoDB-а постављају на нулу, након поновног стартовања сервиса, уколико јеMySQL табела празна, што није било случај са MyISAM engine-ом који смо до тада годинама користили. Део новог емаил queue система који моментално архивирао послате мејлове је управо стављао систем у ту ситуацију и направио “савршену олују”. Били су тешки дани за ИТ, а и за комплетну Инфостуд групу, али смо убрзо дошли до закључка да ово није једина грешка коју смо морали да откријемо на тежи начин. О свему томе, можда неки следећи пут.
Неке ствари су једноставно морале да се десе. Драго ми је да сам имао подршку колега. Такве ствари ће се дешавати, али ако имате разумевање шефа и колега све је лакше, то је једноставно живот програмера. Грешке ће се дешавати, хтели ми то или не. Само је можда потребно понекад смирити се, стати на лопту, мало више размислити, не улазити у опасне ствари, не улазити петком, када сте нервозни и оптерећени. Инфостуд је тада био једноставнији систем, али било је лакше направити грешку. У последњих неколико година градили смо инфраструктуру у којој је то све теже и како се та инфраструктира развија, младе колеге тешко могу да се нађу у ситуацији као ми пре пар година. Обавеза сениора сада је да својим искуствима покаже какве грешке могу да се десе ако се систем не развија. Тиме Борко из ИТ тима сајта Послови.Инфостуд завршава своју причу.
Дакле, запамтите. Нове ствари никад не пуштајте петком, не експериментишите при крају радног времена, ваше грешке могу да утичу на цео бизнис и ако колега поред вас почне да хипервентилира, сигурно је био неки гадан qуерy.
