Двајца во кутија (ако можеш) и сите во документација (секогаш).
Во ИТ контекст, „два во кутија“ се однесува на два сервери или компоненти кои се дизајнирани да работат заедно за да обезбедат вишок и зголемена доверливост. Ова поставување може да обезбеди дека ако една компонента не успее, другата ќе ги преземе нејзините операции, со што ќе се одржи континуитетот на услугата. Целта да се има „два во кутија“ е да се обезбеди висока достапност и обновување при катастрофи. Ова исто така важи и за човечките улоги во организацијата; сепак ретко се спроведува.
Ајде да погледнеме релевантен пример на Analytics. Веројатно сите знаеме по име личност во нашата компанија или организација која е „одат-на“ личност за Аналитика. Тие се оние кои имаат извештаи или контролни табли именувани по нив - Извештај на Мајк или Контролна табла на Џејн. Секако, има и други луѓе кои знаат аналитика, но ова се вистинските шампиони кои се чини дека знаат како да ги завршат најтешките работи и да ги надминат роковите. Прашањето е што овие луѓе стојат сами. Во многу случаи под притисок, тие не работат со никого бидејќи тоа може да ги забави и тука започнува проблемот. Никогаш не мислиме дека ќе ја изгубиме оваа личност. Ќе се воздржам од типичното „да речеме дека ќе ги удри автобус“ или користење на пример за искористување на моменталните можности на пазарот на труд и ќе кажам нешто позитивно како „тие победија на лотарија!“, затоа што сите ние треба да дадеме свој дел за да бидеме позитивни. овие денови.
Приказната
Доаѓа понеделник наутро, а нашиот експерт за аналитика и шампион МЈ поднесе оставка. МЈ доби на лотарија и веќе ја напушти земјата без грижа во светот. Тимот и луѓето кои го познаваат МЈ се воодушевени и љубоморни, но сепак работата мора да оди. Сега е кога ќе се разбере вредноста и реалноста на она што го правеше МЈ. МЈ беше одговорен за конечното објавување и валидација на аналитиката. Тие секогаш се чинеше дека можат да ја подобрат ефикасноста или да ја направат таа тешка промена пред да ја достават аналитиката на сите. На никого не му беше грижа како тоа е направено и беше безбеден со фактот дека тоа штотуку се случи, а MJ беше индивидуална Rock Star на Analytics, така што беше дадено ниво на автономија. Сега кога тимот почнува да ги собира парчињата, барањата, секојдневните проблеми, барањата за модификација, тие се во загуба и почнуваат да се препукуваат. Извештаи / Контролни табли се наоѓаат во непознати состојби; некои средства не се ажурираа во текот на викендот и не знаеме зошто; луѓето прашуваат што се случува и кога работите ќе се поправат, уредувањата за кои МЈ рече дека се завршени не се појавуваат и немаме идеја зошто. Тимот изгледа лошо. Тоа е катастрофа и сега сите го мразиме МЈ.
Лекциите
Постојат некои лесни и очигледни средства за носење.
- Никогаш не дозволувајте поединецот да работи сам. Звучи добро, но во помалите агилни тимови, немаме време или луѓе да го реализираме ова. Луѓето доаѓаат и си одат, задачите се многу, па во име на продуктивноста е раздели и владеј.
- Секој мора да го сподели своето знаење. Исто така звучи добро, но дали споделуваме со вистинската личност или луѓе? Имајте на ум дека многу добитници на лотарија се соработници. Правењето сесии за споделување знаење, исто така, одзема време од задачите и повеќето луѓе инвестираат само во вештини и знаење точно на време кога тоа е потребно.
Значи, кои се некои вистински решенија што секој може да ги спроведе и да ги остави зад себе?
Да почнеме со Управување со конфигурација. Ќе го користиме ова како чадор термин за неколку слични теми.
- Управување со промени: Процесот на планирање, спроведување и контролирање на промените во софтверските системи на структуриран и систематски начин. Овој процес има за цел да осигура дека промените се направени на контролиран и ефикасен начин (со можност за враќање), со минимално нарушување на постоечкиот систем и максимална корист за организацијата.
- Управување со проекти: Планирање, организација и контрола на проектите за развој на софтвер за да се осигура дека тие се завршени на време, во рамките на буџетот и според посакуваните стандарди за квалитет. Тоа вклучува координација на ресурсите, активностите и задачите во текот на животниот циклус на развој на софтвер за да се постигнат целите на проектот и да се испорача софтверскиот производ на распоред.
- Континуирана интеграција и континуирана испорака (CI/CD): Процесот на автоматизирање на зградата, тестирање и распоредување на софтвер. Континуираната интеграција бара редовно спојување на промените на кодот во споделено складиште и извршување на автоматизирани тестови за откривање на грешки на почетокот на процесот на развој. Континуирана испорака/распоредување вклучува автоматско ослободување на тестираните и потврдени промени на кодот во производството, што овозможува брзо и често објавување на нови функции и подобрувања.
- Контрола на верзијата: Процесот на управување со промените на изворниот код и другите софтверски артефакти со текот на времето користејќи специјализирани софтверски алатки. Тоа им овозможува на програмерите да соработуваат на база на кодови, да одржуваат целосна историја на промени и да експериментираат со нови функции без да влијаат на главната база на кодови.
Сето горенаведено се однесува на добри практики за развој на софтвер. Аналитиките што го поттикнуваат и водат бизнисот не заслужуваат ништо помалку, бидејќи тие се клучни за донесување одлуки. Сите аналитички средства (ETL работни места, семантички дефиниции, дефиниции за метрика, извештаи, контролни табли, приказни... итн) се само фрагменти од код со визуелен интерфејс за дизајнирање и навидум мали промени можат да мирисаат на хаос во операциите.
Користењето на Управување со конфигурација нè покрива да продолжиме да работиме во добра состојба. Средствата се верзии за да можеме да видиме што се случило во нивниот животен век, знаеме кој на што работи заедно со постигнатиот напредок и временските рокови, и знаеме дека производството ќе продолжи. Она што не е опфатено со ниту еден чист процес е пренесувањето на знаењето и разбирањето зошто работите се такви какви што се.
Секој систем, база на податоци и алатка за аналитика имаат свои необичности. Работи што ги тераат да одат брзо или бавно, предмети што ги тераат да се однесуваат на одреден начин или да го дадат посакуваниот резултат. Овие можат да бидат поставки на системско или глобално ниво или работи во дизајнот на средствата што ги тераат да работат исто како што треба. Проблемот е што повеќето од овие работи се учат со текот на времето и не секогаш има каде да се документираат. Дури и кога преминуваме во Cloud системи каде што повеќе не контролираме како се извршува апликацијата и се потпираме на добавувачот да го направи тоа што е можно побрзо, дотерувањето на дефинициите продолжува во нашите средства за да го отклучиме токму она што го бараме. Ова знаење е она што треба да се долови и сподели со тоа што ќе им биде достапно на другите. Ова знаење треба да се бара како дел од документацијата на средствата и да биде составен дел од контролата на верзијата и процесот на проверка и одобрување на CI/CD, а во некои случаи дури и како дел од списокот за проверка пред да се објават работи што треба да се направат и не направи.
Нема магични одговори или вештачка интелигенција за да се прикријат кратенки во нашите аналитички процеси или недостаток од нив. Без оглед на големината на тимот што ги одржува податоците и аналитиката во протокот, инвестицијата во системот за следење на промените, верзија на сите средства и помош за документирање на процесот на развој и собирање на знаење е задолжителна. Инвестирањето во процесите и времето однапред ќе заштеди еден тон потрошено време подоцна да ги откриеме работите за да ја одржиме здравата состојба на нашата аналитика. Работите се случуваат и најдобро е да имате полиса за осигурување за МЈ и други добитници на лотарија.
