Двама в кутия (ако можете) и всички в документация (винаги).
В ИТ контекст „двама в кутия“ се отнася до два сървъра или компонента, които са проектирани да работят заедно, за да осигурят излишък и повишена надеждност. Тази настройка може да гарантира, че ако един компонент се повреди, другият ще поеме неговите операции, като по този начин се поддържа непрекъснатостта на услугата. Целта на наличието на „две в кутия“ е да се осигури висока наличност и възстановяване след бедствие. Това се отнася и за човешките роли в една организация; обаче рядко се прилага.
Нека разгледаме подходящ пример за Google Анализ. Вероятно всички ние познаваме човек в нашата компания или организация по име, който е най-подходящият за Google Анализ. Те са тези, които имат отчети или табла за управление, кръстени на тях – Докладът на Майк или Таблото на Джейн. Разбира се, има и други хора, които познават анализите, но това са истинските шампиони, които изглежда знаят как да свършат най-трудните неща и да надхвърлят крайните срокове. Въпросът е, че тези хора стоят сами. В много случаи под напрежение те не работят с никого, тъй като това може да ги забави и тук започва проблемът. Никога не мислим, че ще загубим този човек. Ще се въздържа от типичното „да кажем, че ги блъсна автобус“ или ще използвам пример, използващ настоящите възможности на пазара на труда, и ще кажа нещо положително като „те спечелиха от лотарията!“, защото всички ние трябва да направим своята част, за да бъдем позитивни Тези дни.
Историята
Идва понеделник сутрин и нашият експерт по анализи и шампион MJ подаде оставката си. MJ спечели от лотарията и вече е напуснал страната без никакви грижи. Екипът и хората, които познават MJ, са развълнувани и ревниви, но работата трябва да продължи. Сега е моментът, когато стойността и реалността на това, което правеше MJ, ще бъде разбрана. MJ беше отговорен за окончателното публикуване и валидиране на анализа. Те винаги изглеждаха способни да подобрят ефективността или да направят тази трудна промяна, преди да предоставят анализите на всички. Никой не се интересуваше как е направено и беше сигурен във факта, че току-що се случи, а MJ беше индивидуална рок звезда на Анализ, така че беше дадено ниво на автономност. Сега, когато екипът започва да събира парчетата, заявките, ежедневните проблеми, исканията за модификация, те са на загуба и започват да се борят. Отчетите / Таблата за управление са намерени в неизвестни състояния; някои активи не се актуализираха през уикенда и ние не знаем защо; хората питат какво става и кога нещата ще бъдат поправени, редакциите, които MJ каза, че са направени, не се показват и ние нямаме представа защо. Отборът изглежда зле. Това е катастрофа и сега всички мразим MJ.
Уроците
Има някои лесни и очевидни изводи.
- Никога не позволявайте на човек да работи сам. Звучи добре, но в по-малките гъвкави екипи нямаме време или хора, които да направят това да се случи. Хората идват и си отиват, задачите са много, така че е разделяй и владей в името на продуктивността.
- Всеки трябва да споделя знанията си. Също така звучи добре, но дали споделяме с правилния човек или хора? Имайте предвид, че много печеливши от лотарията са колеги. Провеждането на сесии за споделяне на знания също отнема време от задачите и повечето хора инвестират в умения и знания само навреме, когато са необходими.
И така, кои са някои реални решения, които всеки може да приложи и да изостане?
Да започнем с Управление на конфигурацията. Ще използваме това като общ термин за няколко подобни теми.
- Управление на промените: Процесът на планиране, внедряване и контролиране на промени в софтуерните системи по структуриран и систематичен начин. Този процес има за цел да гарантира, че промените се правят по контролиран и ефективен начин (с възможност за връщане), с минимално прекъсване на съществуващата система и максимална полза за организацията.
- Управление на проекти: Планиране, организация и контрол на проекти за разработка на софтуер, за да се гарантира, че са завършени навреме, в рамките на бюджета и според желаните стандарти за качество. Това включва координиране на ресурси, дейности и задачи през целия жизнен цикъл на разработка на софтуер, за да се постигнат целите на проекта и да се достави софтуерният продукт по график.
- Непрекъсната интеграция и непрекъсната доставка (CI/CD): Процесът на автоматизиране на изграждането, тестването и внедряването на софтуер. Непрекъснатата интеграция изисква редовно обединяване на промените в кода в споделено хранилище и провеждане на автоматизирани тестове за откриване на грешки в началото на процеса на разработка. Непрекъснатото доставяне/разгръщане включва автоматично пускане на тествани и валидирани промени в кода в производство, което позволява бързо и често пускане на нови функции и подобрения.
- Контрол на версиите: Процесът на управление на промените в изходния код и други софтуерни артефакти във времето с помощта на специализирани софтуерни инструменти. Той позволява на разработчиците да си сътрудничат върху кодова база, да поддържат пълна история на промените и да експериментират с нови функции, без да засягат основната кодова база.
Всичко по-горе се отнася за добри практики за разработка на софтуер. Анализите, които движат и управляват бизнеса, заслужават не по-малко, тъй като са от решаващо значение за вземането на решения. Всички аналитични активи (ETL задания, семантични дефиниции, дефиниции на показатели, отчети, табла за управление, истории… и т.н.) са само кодови фрагменти с визуален интерфейс за проектиране и привидно незначителни промени могат да миришат на хаос в операциите.
Използването на Configuration Management ни позволява да продължим да работим в добро състояние. Активите са с версии, така че можем да видим какво се е случило през техния жизнен цикъл, знаем кой върху какво работи заедно с постигнатия напредък и времеви линии, и знаем, че производството ще продължи. Това, което не се покрива от нито един чист процес, е предаването на знания и разбирането защо нещата са такива, каквито са.
Всяка система, база данни и инструмент за анализ имат свои собствени странности. Неща, които ги карат да се движат бързо или бавно, елементи, които ги карат да се държат по определен начин или да постигат желания резултат. Това могат да бъдат настройки на системно или глобално ниво или неща в дизайна на активите, които ги карат да работят точно както трябва. Проблемът е, че повечето от тези неща се научават с времето и не винаги има къде да се документират. Дори когато преминаваме към облачни системи, където вече не контролираме как се изпълнява приложението и разчитаме на доставчика да го направи възможно най-бързо, настройването на дефинициите продължава в нашите активи, за да отключим точно това, което търсим. Това знание е това, което трябва да бъде уловено и споделено, като се направи достъпно за другите. Тези знания трябва да се изискват като част от документацията на активите и да станат неразделна част от процеса на проверка и одобрение за контрол на версиите и CI/CD, а в някои случаи дори като част от контролен списък преди публикуване на неща, които трябва да се направят, а не направи.
Няма магически отговори или изкуствен интелект, които да покриват преките пътища в нашите аналитични процеси или липсата на такива. Независимо от размера на екипа, който поддържа движението на данните и анализа, инвестицията в система за проследяване на промените, версия на всички активи и помощ за документиране на процеса на разработка и събиране на знания е задължителна. Инвестицията в процеси и време отпред ще спести много загубено време по-късно за измисляне на нещата, за да поддържаме здравословно състояние на нашите анализи. Нещата се случват и е най-добре да имате застрахователна полица за MJ и други победители от лотарията.
