Два ў скрынцы (калі можна) і ўсе ў дакументацыі (заўсёды).
У ІТ-кантэксце «два ў скрынцы» адносіцца да двух сервераў або кампанентаў, якія прызначаны для сумеснай працы для забеспячэння рэзервавання і павышэння надзейнасці. Гэтая ўстаноўка можа гарантаваць, што калі адзін кампанент выйдзе з ладу, другі возьме на сябе яго аперацыі, такім чынам падтрымліваючы бесперапыннасць абслугоўвання. Мэта «два ў скрынцы» - забяспечыць высокую даступнасць і аварыйнае аднаўленне. Гэта таксама адносіцца да роляў чалавека ў арганізацыі; аднак гэта рэдка рэалізуецца.
Давайце разгледзім адпаведны прыклад Analytics. Верагодна, мы ўсе ведаем чалавека ў нашай кампаніі або арганізацыі па імені, які з'яўляецца галоўным чалавекам для Analytics. Гэта тыя, у каго ёсць справаздачы або прыборныя панэлі, названыя ў іх гонар - Справаздача Майка або Прыборная панэль Джэйн. Безумоўна, ёсць і іншыя людзі, якія ведаюць аналітыку, але гэта сапраўдныя чэмпіёны, якія, здаецца, ведаюць, як рабіць самыя складаныя рэчы і не выконваць тэрміны. Справа ў тым, што гэтыя людзі стаяць асобна. У многіх выпадках пад ціскам яны ні з кім не працуюць, бо гэта можа іх запаволіць, і тут пачынаецца праблема. Мы ніколі не думаем, што страцім гэтага чалавека. Я ўстрымаюся ад тыповага "дапусцім, іх збіў аўтобус" або ад выкарыстання прыкладу, які выкарыстоўвае цяперашнія магчымасці на рынку працы, і скажу што-небудзь пазітыўнае, напрыклад "яны выйгралі ў латарэю!", таму што мы ўсе павінны ўнесці свой уклад у пазітыўныя адносіны у гэтыя дні.
гісторыя
Надыходзіць раніца панядзелка, і наш эксперт па аналітыцы і чэмпіён MJ падаў у адстаўку. MJ выйграў у латарэю і ўжо пакінуў краіну без клопату ў свеце. Каманда і людзі, якія ведаюць MJ, у захапленні і зайздросцяць, але праца павінна працягвацца. Зараз варта зразумець каштоўнасць і рэальнасць таго, што рабіў MJ. MJ адказваў за канчатковую публікацыю і праверку аналітыкі. Здавалася, што яны заўсёды маглі павысіць эфектыўнасць або ўнесці такія цяжкія змены, перш чым прадастаўляць аналітыку ўсім. Нікога сапраўды не цікавіла, як гэта было зроблена, і ён быў упэўнены ў тым, што гэта проста адбылося, і MJ быў індывідуальнай Рок-зоркай Analytics, таму быў прадастаўлены пэўны ўзровень аўтаноміі. Зараз, калі каманда пачынае збіраць дэталі, запыты, штодзённыя праблемы, запыты на мадыфікацыю, яны губляюцца і пачынаюць змагацца. Справаздачы / панэлі кіравання знаходзяцца ў невядомых штатах; некаторыя актывы не абнаўляліся на выходных, і мы не ведаем чаму; людзі пытаюцца, што адбываецца і калі ўсё будзе выпраўлена, праўкі, якія MJ сказаў, што зроблены, не адлюстроўваюцца, і мы паняцця не маем, чаму. Каманда выглядае дрэнна. Гэта катастрофа, і цяпер мы ўсе ненавідзім MJ.
Урокі
Ёсць некалькі простых і відавочных высноваў.
- Ніколі не дазваляйце чалавеку працаваць у адзіночку. Гучыць добра, але ў невялікіх гнуткіх камандах у нас няма часу або людзей, каб гэта зрабіць. Людзі прыходзяць і сыходзяць, задач шмат, таму падзяляй і ўладар у імя прадукцыйнасці.
- Кожны павінен дзяліцца сваімі ведамі. Таксама гучыць добра, але ці дзелімся мы з патрэбным чалавекам або людзьмі? Майце на ўвазе, што многія пераможцы латарэі з'яўляюцца калегамі. Правядзенне заняткаў па абмене ведамі таксама адымае час ад задач, і большасць людзей укладваюць грошы ў навыкі і веды толькі ў той момант, калі гэта неабходна.
Такім чынам, якія рэальныя рашэнні, якія кожны можа рэалізаваць і адстаць ад іх?
Пачнем з кіравання канфігурацыяй. Мы будзем выкарыстоўваць гэта як агульны тэрмін для некалькіх падобных тэм.
- Кіраванне зменамі: Працэс планавання, укаранення і кантролю змяненняў у праграмных сістэмах у структураванай і сістэматычнай форме. Гэты працэс накіраваны на забеспячэнне таго, каб змены ўносіліся кантраляваным і эфектыўным чынам (з магчымасцю вяртання), з мінімальным парушэннем існуючай сістэмы і максімальнай выгадай для арганізацыі.
- Кіраваньне праектам: Планаванне, арганізацыя і кантроль праектаў па распрацоўцы праграмнага забеспячэння, каб гарантаваць іх выкананне ў тэрмін, у межах бюджэту і ў адпаведнасці з жаданымі стандартамі якасці. Гэта ўключае ў сябе каардынацыю рэсурсаў, мерапрыемстваў і задач на працягу ўсяго жыццёвага цыкла распрацоўкі праграмнага забеспячэння для дасягнення мэтаў праекта і пастаўкі праграмнага прадукту па графіку.
- Бесперапынная інтэграцыя і бесперапынная пастаўка (CI/CD): Працэс аўтаматызацыі стварэння, тэсціравання і разгортвання праграмнага забеспячэння. Бесперапынная інтэграцыя патрабуе рэгулярнага аб'яднання змен кода ў агульнае сховішча і выканання аўтаматычных тэстаў для выяўлення памылак на ранніх стадыях працэсу распрацоўкі. Бесперапынная пастаўка/разгортванне прадугледжвае аўтаматычны выпуск правераных і пацверджаных змен кода ў вытворчасць, што дазваляе хутка і часта выпускаць новыя функцыі і паляпшэнні.
- Кантроль версій: Працэс кіравання зменамі зыходнага кода і іншых праграмных артэфактаў з цягам часу з дапамогай спецыялізаваных праграмных сродкаў. Гэта дазваляе распрацоўшчыкам супрацоўнічаць над кодавай базай, захоўваць поўную гісторыю змяненняў і эксперыментаваць з новымі функцыямі, не закранаючы асноўную кодавую базу.
Усё вышэйсказанае адносіцца да добрай практыкі распрацоўкі праграмнага забеспячэння. Аналітыка, якая рухае і вядзе бізнес, заслугоўвае не меншага, паколькі яна мае вырашальнае значэнне для прыняцця рашэнняў. Усе аналітычныя актывы (заданні ETL, семантычныя вызначэнні, вызначэнні паказчыкаў, справаздачы, прыборныя панэлі, гісторыі ... і г.д.) - гэта проста фрагменты кода з візуальным інтэрфейсам для праектавання, і, здавалася б, нязначныя змены могуць пахнуць хаосам для аперацый.
Выкарыстанне кіравання канфігурацыяй дазваляе нам працягваць працаваць у добрым стане. Актывы маюць версіі, каб мы маглі бачыць, што адбылося на працягу іх жыцця, мы ведаем, хто над чым працуе разам з дасягнутым прагрэсам і тэрмінамі, і мы ведаем, што вытворчасць будзе працягвацца. Тое, што не ахопліваецца ніякім чыстым працэсам, - гэта перадача ведаў і разуменне таго, чаму ўсё так, як ёсць.
Кожная сістэма, база дадзеных і інструмент аналітыкі маюць свае асаблівасці. Рэчы, якія прымушаюць іх рухацца хутка або павольна, прадметы, якія прымушаюць іх паводзіць сябе пэўным чынам або даць жаданы вынік. Гэта могуць быць налады на сістэмным або глабальным узроўні або рэчы ў канструкцыі актываў, якія прымушаюць іх працаваць так, як трэба. Праблема ў тым, што большасць з гэтых рэчаў вывучаюцца з цягам часу, і не заўсёды ёсць месца, каб іх дакументаваць. Нават калі мы пераходзім да воблачных сістэм, дзе мы больш не кантралюем, як выконваецца прыкладанне, і мы разлічваем на пастаўшчыка, каб зрабіць гэта як мага хутчэй, налада азначэнняў працягваецца ў нашых актывах, каб разблакіраваць менавіта тое, што мы шукаем. Гэтыя веды трэба захоўваць і дзяліцца імі, робячы іх даступнымі для іншых. Гэтыя веды павінны патрабавацца як частка дакументацыі аб актывах і быць неад'емнай часткай кантролю версій і працэсу рэгістрацыі і зацвярджэння CI/CD, а ў некаторых выпадках нават як частка кантрольнага спісу перад публікацыяй спраў, якія трэба зрабіць, а не рабіць.
Няма чароўных адказаў або штучнага інтэлекту, каб прыкрыць ярлыкі ў нашых аналітычных працэсах або іх адсутнасць. Незалежна ад памеру каманды, якая падтрымлівае даныя і аналітыку, інвестыцыі ў сістэму для адсочвання змяненняў, версіі ўсіх актываў і дапамогі ў дакументаванні працэсу распрацоўкі і збору ведаў з'яўляюцца абавязковымі. Заўчасныя інвестыцыі ў працэсы і час зэканомяць масу марна патрачанага часу на высвятленне рэчаў, каб падтрымліваць здаровы стан нашай аналітыкі. Усё здараецца, і лепш мець страхавы поліс для MJ і іншых пераможцаў латарэі.
