Dalawa sa isang kahon (kung maaari mo) at lahat ng nasa dokumentasyon (palaging).
Sa isang konteksto ng IT, ang "dalawa sa isang kahon" ay tumutukoy sa dalawang server o mga bahagi na idinisenyo upang magtulungan upang magbigay ng redundancy at mas mataas na pagiging maaasahan. Ang setup na ito ay maaaring matiyak na kung ang isang bahagi ay nabigo, ang isa pa ay kukuha sa mga operasyon nito, kaya pinapanatili ang pagpapatuloy ng serbisyo. Ang layunin ng pagkakaroon ng "dalawa sa isang kahon" ay upang magbigay ng mataas na kakayahang magamit at pagbawi sa sakuna. Nalalapat din ito sa mga tungkulin ng tao sa isang organisasyon; gayunpaman, ito ay bihirang ipatupad.
Tingnan natin ang isang nauugnay na halimbawa ng Analytics. Malamang na kilala nating lahat ang isang tao sa ating kumpanya o organisasyon sa pangalan na siyang "go-to" na tao para sa Analytics. Sila ang may mga ulat o dashboard na ipinangalan sa kanila – Ulat ni Mike o Dashboard ni Jane. Oo naman, may iba pang mga tao na alam ng analytics, ngunit ito ang mga tunay na kampeon na tila alam kung paano gawin ang pinakamahirap na bagay at maabot ang mga deadline. Ang isyu ay ang mga taong ito ay nag-iisa. Sa maraming mga kaso sa ilalim ng presyon, hindi sila nakikipagtulungan sa sinuman dahil maaaring makapagpabagal ito sa kanila at dito magsisimula ang problema. Hindi namin akalain na mawawala sa amin ang taong ito. Iiwas ako sa karaniwang "sabihin na nating masagasaan sila ng bus" o gumamit ng isang halimbawa na gumagamit ng kasalukuyang mga pagkakataon sa merkado ng trabaho at magsasabi ng positibong tulad ng "nanalo sila sa lottery!", dahil dapat tayong lahat ay gawin ang ating bahagi upang maging positibo. sa mga araw na ito.
Ang Story
Dumating ang Lunes ng umaga, at ang aming analytics expert at champion na si MJ ay nagsumite ng kanilang pagbibitiw. Nanalo si MJ sa lotto at nakaalis na ng bansa ng walang pakialam sa mundo. Ang koponan at mga taong nakakakilala kay MJ ay kinikilig at nagseselos, gayunpaman, dapat na magtrabaho. Ngayon ay malapit nang mauunawaan ang halaga at katotohanan ng ginagawa ni MJ. Responsable si MJ para sa huling pag-publish at pagpapatunay ng analytics. Mukhang palagi nilang nagagawang mapabuti ang kahusayan o gawin ang mahirap na pagbabagong iyon bago ibigay ang analytics sa lahat. Walang talagang nagmamalasakit kung paano ito nagawa at ligtas sa katotohanang nangyari lang ito, at si MJ ay isang Analytics individual na Rock Star kaya isang antas ng awtonomiya ang ipinagkaloob. Ngayon habang ang koponan ay nagsisimulang kunin ang mga piraso, ang mga kahilingan, ang mga pang-araw-araw na isyu, ang mga kahilingan sa pagbabago ay nawawala ang mga ito at nagsimulang mag-agawan. Ang mga ulat / Dashboard ay matatagpuan sa hindi kilalang mga estado; ilang asset ang hindi nag-update noong weekend, at hindi namin alam kung bakit; ang mga tao ay nagtatanong kung ano ang nangyayari at kung kailan ang mga bagay ay maayos, ang mga pag-edit na sinabi ni MJ ay hindi lumalabas at wala kaming ideya kung bakit. Mukhang masama ang team. Ito ay isang kapahamakan at ngayon lahat tayo ay galit kay MJ.
Ang mga aralin
Mayroong ilang madali at halatang take-aways.
- Huwag pahintulutan ang isang indibidwal na magtrabaho nang mag-isa. Mukhang maganda pero sa mas maliliit na agile team, wala kaming oras o ang mga tao para gawin ito. Ang mga tao ay dumarating at umalis, ang mga gawain ay marami, kaya ito ay hatiin at lupigin sa ngalan ng pagiging produktibo.
- Dapat ibahagi ng bawat isa ang kanilang kaalaman. Maganda rin ang pakinggan ngunit nagbabahagi ba tayo sa tamang tao o tao? Tandaan na maraming nanalo sa lottery ang mga katrabaho. Ang paggawa ng mga session ng pagbabahagi ng kaalaman ay nangangailangan din ng oras mula sa mga gawain at karamihan sa mga tao ay namumuhunan lamang sa mga kasanayan at kaalaman sa oras kung kailan ito kinakailangan.
Kaya, ano ang ilang tunay na solusyon na kayang ipatupad at makuha ng lahat?
Magsimula tayo sa Pamamahala ng Configuration. Gagamitin namin ito bilang umbrella term para sa ilang katulad na paksa.
- Baguhin ang Pamamahala: Ang proseso ng pagpaplano, pagpapatupad, at pagkontrol sa mga pagbabago sa mga software system sa isang balangkas at sistematikong paraan. Ang prosesong ito ay naglalayong tiyakin na ang mga pagbabago ay ginawa sa isang kontrolado at mahusay na paraan (na may kakayahang bumalik), na may pinakamababang pagkagambala sa kasalukuyang sistema at pinakamataas na benepisyo sa organisasyon.
- Pamamahala ng Proyekto: Ang pagpaplano, organisasyon, at kontrol ng mga proyekto sa pagbuo ng software upang matiyak na nakumpleto ang mga ito sa oras, sa loob ng badyet, at sa nais na mga pamantayan ng kalidad. Ito ay nagsasangkot ng koordinasyon ng mga mapagkukunan, aktibidad, at mga gawain sa buong buhay ng pagbuo ng software upang makamit ang mga layunin ng proyekto at maihatid ang produkto ng software sa iskedyul.
- Patuloy na Pagsasama at Patuloy na Paghahatid (CI/CD): Ang proseso ng pag-automate ng pagbuo, pagsubok, at pag-deploy ng software. Nangangailangan ang Continuous Integration ng regular na pagsasama-sama ng mga pagbabago sa code sa isang shared repository at pagpapatakbo ng mga automated na pagsubok upang matukoy ang mga error nang maaga sa proseso ng pag-develop. Ang Tuloy-tuloy na Paghahatid/Pag-deploy ay nagsasangkot ng awtomatikong pagpapalabas ng nasubok at napatunayang mga pagbabago sa code sa produksyon, na nagbibigay-daan para sa mabilis at madalas na paglabas ng mga bagong feature at pagpapahusay.
- Kontrol sa Bersyon: Ang proseso ng pamamahala ng mga pagbabago sa source code at iba pang mga artifact ng software sa paglipas ng panahon gamit ang mga espesyal na tool ng software. Nagbibigay-daan ito sa mga developer na mag-collaborate sa isang codebase, magpanatili ng kumpletong kasaysayan ng mga pagbabago, at mag-eksperimento sa mga bagong feature nang hindi naaapektuhan ang pangunahing codebase.
Ang lahat ng nasa itaas ay tumutukoy sa mahusay na mga kasanayan sa pagbuo ng software. Ang mga Analytics na nagtutulak at nagpapatakbo ng negosyo ay karapat-dapat din dahil sila ay kritikal sa misyon sa paggawa ng desisyon. Ang lahat ng mga asset ng analytics (mga trabaho sa ETL, mga semantic na kahulugan, mga kahulugan ng sukatan, mga ulat, mga dashboard, mga kuwento...atbp) ay mga snippet lang ng code na may visual na interface para sa pagdidisenyo at ang tila maliliit na pagbabago ay maaaring magdulot ng pinsala sa mga operasyon.
Ang paggamit ng Configuration Management ay sumasaklaw sa amin upang patuloy na tumakbo sa isang mahusay na estado. Ang mga asset ay versioned para makita natin kung ano ang nangyari sa kanilang life span, alam natin kung sino ang gumagawa sa kung ano kasama ang progress na ginawa at mga timeline, at alam natin na magpapatuloy ang production. Ang hindi saklaw ng anumang dalisay na proseso ay ang paglilipat ng kaalaman at ang pag-unawa kung bakit ganito ang mga bagay.
Ang bawat system, database, at analytics tool ay may sariling quirks. Mga bagay na nagpapabilis o nagpapabagal sa kanila, mga bagay na nagpapakilos sa kanila sa isang tiyak na paraan o nagdudulot ng ninanais na resulta. Ang mga ito ay maaaring mga setting sa isang sistema o pandaigdigang antas o mga bagay sa loob ng disenyo ng asset na nagpapatakbo sa mga ito tulad ng nararapat. Ang problema ay ang karamihan sa mga bagay na ito ay natutunan sa paglipas ng panahon at hindi palaging isang lugar upang idokumento ang mga ito. Kahit na lumipat kami sa mga Cloud system kung saan hindi na namin kinokontrol kung paano ipapatupad ang application at umaasa kami sa supplier na gawin itong mas mabilis hangga't maaari, nagpapatuloy ang pagsasaayos ng mga kahulugan sa loob ng aming mga asset upang i-unlock ang eksaktong hinahanap namin. Ang kaalamang ito ang kailangang makuha at ibahagi sa pamamagitan ng paggawa nito sa iba. Kailangang kailanganin ang kaalamang ito bilang bahagi ng dokumentasyon ng mga asset at ginawang mahalagang bahagi ng kontrol ng bersyon at proseso ng pag-check in at pag-apruba ng CI/CD at sa ilang mga kaso kahit na bilang bahagi ng checklist bago mag-publish ng mga bagay na dapat gawin at hindi. gawin.
Walang mahiwagang sagot o AI upang takpan ang mga shortcut sa aming mga proseso ng analytics o kulang doon. Anuman ang laki ng team na nagpapanatili sa data at analytics na dumadaloy bilang isang pamumuhunan sa isang system para subaybayan ang mga pagbabago, i-version ang lahat ng asset at tulong upang idokumento ang proseso ng pagbuo at pagkuha ng kaalaman ay kinakailangan. Ang pamumuhunan sa mga proseso at oras nang maaga ay makakatipid ng isang toneladang nasayang na oras sa pag-iisip ng mga bagay-bagay upang mapanatili ang isang malusog na estado ng aming analytics. Nangyayari ang mga bagay at pinakamahusay na magkaroon ng patakaran sa seguro para sa mga MJ at iba pang nanalo sa lottery.
