Když zavádíte nový nástroj, programovací jazyk nebo závislost do svého prostředí, jaké kroky podniknete k jejich vyhodnocení? V tomto článku projdu rámcem šesti otázek, který používám pro tato určení.
Jaký problém se snažím vyřešit?
Všichni jsme chyceni do detailů bezprostředního problému. Poctivé a kritické hodnocení pomáhá odhalit širší základní příčiny a zabraňuje mikrooptimalizacím.
[ Také by se vám mohlo líbit: Šest kroků nasazení pro služby Linux a související nástroje ]
Řekněme, že máte problémy se systémem správy konfigurace. Každodenní provozní úkoly trvají déle, než by měly, a práce s jazykem je obtížná. Nový systém správy konfigurace může tyto obavy zmírnit, ale nezapomeňte se na kontext tohoto systému podívat blíže. Možná, že přechod z virtuálních počítačů na neměnné kontejnery tyto problémy a ještě více zmírní ve vašem prostředí a zároveň bude ekvivalentní množství práce. V tomto bodě byste měli prozkoumat také proveditelnost komplexnějších řešení. Můžete se rozhodnout, že tento projekt není pro organizaci v tuto chvíli proveditelný kvůli nedostatku organizačních znalostí o kontejnerech, ale svědomité přijetí tohoto kompromisu vám umožní zařadit kontejnery do plánu na další čtvrtletí.
Toto intelektuální cvičení vám pomůže proniknout ke kořenovým příčinám a vyřešit základní problémy, nikoli příznaky větších problémů. Ne vždy to bude možné, ale toto rozhodnutí udělejte záměrně.
Vyřeší tento nástroj tento problém?
Nyní, když jsme identifikovali problém, je čas na kritické zhodnocení jak nás samotných, tak zvoleného nástroje.
Konkrétní technologie se může zdát přitažlivá, protože je nová, protože jste si o ní přečetli skvělý příspěvek na blogu nebo chcete být tím, kdo přednáší na konferenci. Zvonky a píšťalky mohou být hezké, ale tento nástroj musí vyřešit základní problémy, které jste identifikovali v první otázce.
Čeho se vzdávám?
Nástroj ve skutečnosti problém vyřeší a my víme, že řešíme správně problém, ale jaké jsou kompromisy?
Tyto úvahy mohou být čistě technické. Bude nedostatek nástrojů pro sledování bránit efektivnímu ladění ve výrobě? Znesnadňuje povaha tohoto nástroje uzavřeného zdroje hledání drobných chyb? Stojí správa další závislosti za provozní výhody používání tohoto nástroje?
Kromě toho zahrňte větší organizační, obchodní a právní kontexty, v nichž působíte.
Vzdáváte se kontroly nad důležitým obchodním pracovním postupem ve prospěch dodavatele třetí strany? Pokud tento dodavatel zdvojnásobí své náklady na API, je to něco, co si vaše organizace může dovolit a je ochotna akceptovat? Jste spokojeni s nástroji s uzavřeným zdrojovým kódem, které zpracovávají citlivou část proprietárních informací? Znesnadňuje licencování softwaru jeho komerční použití?
I když to nejsou jednoduché otázky, na které je třeba odpovědět, věnujte si čas tomu, abyste je předem vyhodnotili, ušetří vám to později spoustu bolesti.
Je projekt nebo dodavatel v pořádku?
Tato otázka přichází s dodatkem „pro vyváženost vašich požadavků“. Pokud potřebujete pouze nástroj, který váš tým dostane přes čtyři až šest měsíců do Projektu X je kompletní, stává se tato otázka méně důležitou. Pokud se jedná o víceletý závazek a nástroj řídí kritický obchodní pracovní postup, je to problém.
Při provádění tohoto kroku využijte všechny dostupné zdroje. Pokud je řešením open source, prohlédněte si historii odevzdání, e-mailové konference a diskuse na fóru o tomto softwaru. Zdá se, že komunita efektivně komunikuje a dobře spolupracuje, nebo jsou mezi členy komunity zjevné rozpory? Pokud součástí toho, co kupujete, je smlouva o podpoře, použijte tuto podporu ve fázi ověření koncepce. Splňuje vaše očekávání? Stojí kvalita podpory za cenu?
Při hodnocení nástrojů s otevřeným zdrojovým kódem se také ujistěte, že jste udělali krok za hvězdami a větvemi GitHubu. Něco by se mohlo dostat na titulní stránku agregátoru zpráv a upoutat pozornost na několik dní, ale hlubší pohled by mohl odhalit, že na projektu skutečně pracuje pouze několik hlavních vývojářů a ti mají potíže s hledáním příspěvků zvenčí. Možná je nástroj open source, ale vývoj jádra řídí tým financovaný společností a podpora pravděpodobně skončí, pokud tato organizace projekt opustí. Možná se API měnilo každých šest měsíců, což lidem, kteří přijali dřívější verze, způsobuje spoustu bolesti.
Jaká jsou rizika?
Jako technolog chápete, že nikdy nic nejde podle plánu. Sítě vypadnou, disky selžou, servery se restartují, řádky v datovém centru ztrácejí energii, celé oblasti AWS se stanou nedostupnými nebo únosy BGP přesměrují stovky terabajtů internetového provozu.
Zeptejte se sami sebe, jak by toto nářadí mohlo selhat a jaký by to mělo dopad. Pokud do svého kanálu CI/CD přidáváte produkt dodavatele zabezpečení, co se stane, když daný prodejce přestane fungovat?
To přináší jak technické, tak obchodní úvahy. Vyprší časový limit kanálů CI/CD, protože se nemohou dostat k prodejci, nebo je máte „selhání otevřené“ a umožníte dokončení potrubí s varováním? Jedná se o technický problém, ale v konečném důsledku jde o obchodní rozhodnutí. Jste ochotni přejít do výroby se změnou, která v tomto scénáři obešla bezpečnostní skenování?
Je zřejmé, že tento úkol se stává obtížnějším, protože zvyšujeme složitost systému. Naštěstí weby jako k8s.af konsolidují příklady scénářů výpadků. Tyto veřejné pitvy jsou velmi užitečné pro pochopení toho, jak může určitý software selhat a jak tento scénář naplánovat.
Jaké jsou náklady?
Primárními faktory jsou zde čas zaměstnance a případně náklady dodavatele. Je tato aplikace SaaS levnější než větší počet zaměstnanců? Pokud s tímto novým nástrojem CI/CD ušetříte každému vývojáři v týmu dvě hodiny denně, vyplatí se to během příštího fiskálního roku?
Je pravda, že ne všechno musí být úsporná nabídka. Možná to nebude nákladově neutrální, pokud vývojářskému týmu ušetříte pár hodin denně, ale odstraníte z jeho každodenního pracovního postupu obrovský blokátor a oni by za to byli mnohem spokojenější. To štěstí pravděpodobně stojí za finanční náklady. Přijímání nových vývojářů je nákladné, proto při těchto výpočtech nepodceňujte hodnotu zvýšeného udržení.
[ Bezplatný průvodce od společnosti Red Hat:5 kroků k automatizaci vašeho podnikání. ]
Sbalit
Doufám, že jste shledali tento rámec srozumitelným, a doporučuji vám jej začlenit do svých vlastních rozhodovacích procesů. Neexistuje žádný univerzální rámec, který by fungoval pro každé rozhodnutí. Nezapomínejte, že někdy budete muset jít se svými vnitřnostmi a rozhodnout se. Standardizovaný proces, jako je tento, vám však pomůže rozlišit mezi okamžiky, kdy můžete kriticky analyzovat rozhodnutí, a okamžiky, kdy potřebujete udělat tento skok.