Provozujeme internetové aplikace bezpečně a dlouhodobě udržitelně
Vyvinutím a spuštěním internetové služby práce nekončí, ani zdaleka. Kromě nezbytných úprav a rozvoje jsou s vlastnictvím a provozováním takové služby spojené další náklady, práce a zodpovědnost. V článku nabízíme takový „checklist“ dlouhodobě udržitelného a bezpečného provozování internetových služeb.
Nálepky:
V praxi se znovu a znovu setkáváme se zákazníky, kteří nechápou dvě hlavní věci nezbytné k provozování internetových aplikací bezpečně a dlouhodobě udržitelně:
- vyvarování se vendor locku, a to jak u sw, tak případně u hw
- že smlouvy, smluvní garance a pokuty nic neřeší (když přijdu o data teď, nezajímá mě až tak moc, jestli vysoudím náhradu škody za 3 roky)
Několik našich klientů např. poslalo svůj web do pekel tím, že si koupili web s líbivým CMS od nějaké české firmy a neuvědomili si, jak je ta firma za pár let začne, třeba i neúmyslně a nechtěně, omezovat a jak bude případně pracné se této závislosti zbavit a migrovat na jiné řešení.
Je dobré si proto uvědomit některé základní principy, kterými je třeba se řídit, pokud chceme, aby naše webová prezentace či aplikace byla dlouhodobě funkční, co nejvíc dostupná a bezpečně provozovaná.
Software a data
Právní vztah ke zdrojovým kódům aplikace
Licence, pod kterou vám autor umožní dílo užívat, by měla zejména umožňovat zásahy do díla vámi nebo jinou stranou, a také by měla umožňovat dílo šířit dále. Mnoho uzavřených licencí např. neumožňuje vytvořit více než dvě kopie – hlavní provozní a zálohu.Taková licence je příliš svazující.
Obecně se doporučuje přijmout dílo pod licencí GPL, BSD, MIT nebo některými z licencí Creative Commons (BY nebo BY-SA).
Umístění zdrojových kódů aplikace
Zdrojové kódy byste měli mít k dispozici v jakýkoliv okamžik. Bez ohledu na to, zda máte zdrojové kódy na svém serveru, na githubu nebo na serveru autora aplikace, měli byste mít vlastní zálohu (včetně historie).
Dostupnost vývojářů pro danou platformu
Ověřte si, že vždy dokážete sehnat vývojáře, který se orientuje v platformě, na které je váš systém postaven. Ověřte to zadáním reálné zakázky malého rozsahu, kterou zadáte jiné společnosti, než kdo je autorem.
Zálohování
Mějte vždy alespoň dvě zálohy dat svého systému. Pokud to okolnosti umožňují, zálohujte nejen uživatelské soubory a databáze, ale i celou aplikaci včetně logů a celý server (servery) včetně logů.
Zálohování databáze provádějte z repliky, minimalizujete tím výpadek (downtime) a zrychlíte samotné zálohování. Sekundární zálohu dělejte z primární zálohy; pokud je primární záloha vytvářena metodou push, sekundární dělejte metodou pull. Přístup k sekundární záloze by měla mít jiná osoba, než kdo má přístup k primární záloze.
Zálohujte tak často, jak je to potřeba. Pokud máte málo dat, která jsou ale velmi variabilní, zálohujte třeba každou hodinu.
Plán pro případ katastrofy
Napište si plán disaster recovery. Naplánujte výpadek služby a zkuste disaster recovery podle tohoto plánu provést.
Počítejte s tím, že obnova dat ze záloh trvá dlouho. Možná zjistíte, že budete potřebovat do infrastruktury zahrnout hot-standby servery, do kterých pak jen dohrajete poslední změny.
Zkuste provést disaster recovery v neděli, ve svátek, na Silvestra nebo o Velikonocích.
Hardware a lidé
Výkon a zátěž
Používejte pro své webové služby proxy servery a balancery. Umožní vám to rychleji reagovat na nenadálé požadavky. DNS failover trvá o řád déle.
Dohled
Monitorujte chod serverů ze dvou nezávislých míst. Kromě vlastního stavu běží/neběží sbírejte i performance data, umožní vám to minimalizovat náklady na infrastrukturu, nebo maximalizovat propustnost
Veďte si přehled problémů, které se s vaším systémem řešily (issue track). Můžete-li, dejte možnost vstupovat do tohoto trackeru vašim klientům.
How To…
Napište si návod k instalaci celého vašeho systému. Návod v pravidelných intervalech testujte a aktualizujte.
Hardware
Vyhněte se investicím do hardware, pokud pro vlastní hardware nemáte opravdu dobré důvody. Většina poskytovatelů IT služeb zároveň hardware prodává a hlavní motivací je pro ně provize z prodeje. Správnou konfigurací lze často snížit náročnost na hardware, v mnohých případech o více než polovinu.
Když už z nějakého důvodu musíte koupit hardware, ověřte si reálnou objednávkou dostupnost náhradních dílů. Často se vyplatí mít více obyčejných serverů než jeden super dokonalý, na který ovšem nikdo nemá náhradní díly skladem.
Příklad za všechny: v jedné firmě koupili server HP-Compaq za ranec peněz. Jelikož byl velmi drahý, byla investice počítaná na pět let. Po konci záruky odešel harddisk v poli. Tuzemské zastoupení bylo schopné dodat nový harddisk stejného typu za cca 10 000 CZK a v termínu 6 týdnů. Kdyby server byl obyčejný, jednak by bylo politicky možné ho po 2–3 letech vyměnit celý, a jednak by náhradní díl byl k dispozici do druhého dne.
Lidé
Důvěřujte lidem, kteří mají přístup do vašeho systému. Paranoidní přístupové systémy jsou extrémně drahé. Nemůžete-li z nějakého důvodu lidem důvěřovat, vyměňte je.
Ideální stav je lidem umožnit prakticky vše, aby je omezení přístupu nebrzdilo v práci, avšak zároveň užívání přístupů logovat, aby nebylo obtížné případného pachatele škody dohledat.
Pokud někomu nedůvěřujete, musíte mu sebrat všechny přístupy do systému a naráz. Často jich bývá mnoho a na různých místech. Je dobré mít aktuální seznam k dispozici, případně mít skript, který to řeší.
Logy
Při sběru logů kombinujte centrální a lokální ukládání. Centrální ukládání umožňuje rychlejší analýzu, lokální zajišťuje uložení dat i v případě potíží se sítí a pod.
Horizontální škálování
Naučte se rozumět horizontálnímu škálování a využívat jej. Údržba malého serveru vždy zabere méně času než údržba velkého serveru. Můžete také škálovat podle přihlášených uživatelů. Budete-li mít výpadek jednoho serveru, je velký rozdíl, jestli vám budou telefonovat všichni klienti, nebo jen každý desátý. Stejně tak v případě, že dojde k poškození souborového systému – je velký rozdíl, jestli oprava proběhne za 10 minut nebo za 100 minut. Navíc můžete (díky proxy) uživateli poslat přátelskou chybovou hlášku, ideálně s odhadem, za jak dlouho se má pokusit o přístup znovu.
Shrnutí
V článku jsme si představili některé základní body, které by měl mít každý provozovatel internetové služby rozmyšlené a podchycené. Zamyslete se nad tím, jestli vaše služba nemá někde slabé místo – především zda má funkční zálohování a disaster recovery scénář, které pomohou vyřešit většinu problémů. Je samosebou důležité katastrofám předcházet, ale spoléhat se na to, že se jim podaří předejít vždy, je čirá bláhovost.
Autor vám přeje, abyste ty katastrofické scénáře nemuseli nikdy použít!
Nerad bych se někoho dotknul, vím, že jsme na linuxovém serveru a tady je kacířstvím hlásat něco jiného než open source, ale vydávat to za jedinou správnou cestu je demagogie.
Spoustě zákazníků vyhovuje zákaznické řešení u stabilní firmy třeba právě proto, že je třeba systém uživatelsky přívětivější, že dokáže víc, že se o své zákazníky postarají lépe – právě proto, že za to všechno dostane někdo zaplaceno.
Kupodivu nepotřebuje zákazník každého půl roku jiného bastlíře, mnohem důležitější je pro ně spolehlivé zázemí.
Přesně tak – u open source projektů je daleko větší pravděpodobnost, že se přestanou vyvíjet (stačí, když na to hlavní protagonista přestane mít čas), a pokud to není projekt z TOP 10, málokdy je komunita tak silná, že v jeho vývoji pokračuje.
To je prostě takový hippiesácký přístup.
1) do komunity počítej i sebe, resp. uživatele – je hloupost o té komunitě mluvit jako o někom třetím, kdo na tebe ideálně má pracovat zadarmo a posluhovat ti – komunita jsme my všichni, každý se může zapojit.
2) Pravděpodobnost, že se na to původní autor vykašle je jak u uzavřeného, tak u svobodného softwaru přibližně stejná. V čem je ale rozdíl je, co se stane potom – v případě nesvobodného softwaru zmizí ten program někde v černé díře, autor si ho vezme do hrobu. V případě svobodného softwaru a programu, o který je zájem*, se vždycky najde pokračovatel.
*) snad se shodneme na tom, že je nesmyslné vyvíjet software, o který zájem není, nebo o který má zájem jen pár subjektů a kde náklady na uživatele/zákazníka jsou enormní.
Taky mě to překvapilo, že jediná správná cesta je open source nebo mít přístup ke zdrojovým kódům aplikace.
Je mi jasné, že pro autora článku jako správce serveru je lepší mít zdrojové kódy a možnost si aplikaci sám upravit nebo sehnat někoho jiného, kdo to udělá.
To ale neni pohled většiny zákazníků. Přesně jak píšeš, spousta zákazníků raději sáhne po firemní aplikaci se smlouvou o údržbu.
Ad „To ale neni pohled většiny zákazníků.“
Dostupné zdrojáky ještě nikoho nezabily ;-)
Ad „raději sáhne po firemní aplikaci se smlouvou o údržbu.“
To se přece nevylučuje – naopak – u svobodného softwaru je častější platit za služby (podpora, záruky), protože za licence se neplatí. Naopak u nesvobodného softwaru mají zákazníci často pocit, že když zaplatí za licenci, více už není třeba – jenže v tom je chyba – zaplacením licenčního poplatku nemají žádnou záruku, že program bude fungovat, jak očekávají, mají dokonce mnohem méně práv než uživatelé svobodného softwaru, kteří si ho stáhli zadarmo z Internetu.
Nemluvě o tom, že pokud jako firma dodáme řešení, tak vážně nejsme zvědavi na nějakého šťourala, který začne hrabat do kódu a aplikaci odstřelí. Klient totiž neřekne „neměl ses v tom hrabat“ ale „ta vaše aplikace je rozbitá, opravte to nebo odstoupíme od smlouvy“.
Pokud chce klient systém spravovat sám, tak není problém na to sepsat smlouvu a zaškolit jejich programátora. Ale dávat přístup ke zdrojákům jen tak, to je nesmysl. A platí to i pro open source. Zásadně nedávat klientovi přístup do míst, kam ho nepotřebuje.
Zdroják klientovi dám, ale pokud chce úpravu, tak pracuji se svou kopií a ne s jeho. Pokud si tam nějaké úpravy udělal a chce po mě nějakou další úpravu, pak je třeba do toho zahrnout i čas nutný na analyzu již upraveného kódu a patřičnou diskuzi na téma, jak požadovaná úprava je kompatibilní s jejich úpravou. To si samozřejmě započítám do ceny.
Jo jo, tenhle přístup se mi též velice líbí.
Dokonce to někdy dojde tak daleko, že klietni si sami implementují úpravu, kterou ale nikdo jiný už nechce = spokojeně využívají svojí fičurku + zároveň dostávají dál „globální“ aktualizace.
Ano, toto je naprosto logické a správné řešení a klient to pochopí, pokud není tupec.
Navíc, pokud je aplikace kvalitní, má mít vysoké pokrytí testy, takže pokud udělá změny třetí strana, můžete spustit testy a pokud nevyjdou, je jasné, že je něco špatně a někdo (jiný než vy) odvedl špatnou práci.
Podla mna je mylne rozdelovat projekty na ‚open-source‘ a ‚stabilne firemne‘. A predovsetkym zrovnavat ‚open-source‘ = ‚zadarmo‘.
Velmi casto su ‚stabilne firemne‘ produkty zalozene na open-source rieseni, pricom firma k nemu poskytuje plateny support/rozsirenia a stara sa o svojich zakaznikov.
Spokojny klient mnohokrat ani netusi (a zazil som to uz viackrat), ze jeho web bezi na ‚nejakom open-source‘ a v klude si masti ego, ze open-source je zlo a ‚on to ma od profi-firmy‘ (v suvislosti s tym, obcas dochadza aj k porusovaniu OS licencie dodavatelom).
Dalsou moznostou je, ze open-source projekt zadarmo ma svoju enterprise odnoz, ktora je, povedzme, tiez open-source, avsak pod nejakou restriktivnejsou licenciou, s podporou, rozsirenymi funkciami, pristupom do zakaznickej sekcie na webe, etc…
Cize, ako tu uz bolo spomenute – ak sa na to clovek pozrie ako na sluzbu, resp. pridanu hodnotu a zahodi tu paranoiu, ze kazdy klient mu chce ukradnut zdrojove kody ;-), da sa krasne s open-source pracovat, prispievat do komunity a zaroven zarabat.
– zdrojove kody – predpokladam, ze clanok pojednava o aplikaciach „na mieru“, nie o seriovkach typu uctovnictvo a podobne – ci uz ide o „lokalne“ aplikacie s hrubym klientom alebo weboviny, lisi sa pristup podla velkosti firmy (hrubo povedane). mala firma je rada, ze ma aplikaciu za rozumne peniaze. ale vsetci nasi velki zakaznici zasadne ziadaju aj kompletne zdrojaky a dokumentaciu, aby bolo mozne v pripade problemov s nami odovzdat udrzbu aplikacie dakomu dalsiemu. a naopak aj my sme preberali viacero bankovin s komplet zdrojakmi. pravne formulacie v zmluvach som nevidel, ale v tomto duchu to zjavne muselo byt koncipovane.
– HW – tu by som bol trocha opatrnejsi – my sme napriklad museli svojho casu zrusit prave lacne servery (ok, nadpriemerne vykonne), kde za porovnatelne bubaky ako stala znacka, bol stale problem udrzat ich v chode – co s tym, ze som do hodiny zohnal nahradu za pokazenu RAM, ked nova zasa blbla? a naozaj to bola RAMka, nie board alebo daco ine. Takze ked ide o firmu otec & syn & 10MB dat, tak samozrejme skladacka, ale pokial ide o vacsiu firmu s desiatkami serverov, tak jednoznacne znacka a zaplateny onsite servis s predlzenymi zarukami. kazda sranda daco stoji, ale ked vrazim do aplikacie par milionov a data maju hodnotu este vacsiu, tak predsa nemozem skrblit na serveroch.
Ad „ale vsetci nasi velki zakaznici zasadne ziadaju aj kompletne zdrojaky a dokumentaciu, aby bolo mozne v pripade problemov s nami odovzdat udrzbu aplikacie dakomu dalsiemu.“
Přesně, větší zákazníci mají už trochu přehled a nenechají se balamutit – nejsou zvědaví na nějakého vykuka, který se těší, jak jim bude další roky prodávat aktualizace a namastí si na nich pořádně kapsu (první verzi jim dá klidně pod cenou – ale na dalších si přijde na své, protože má „monopol“ a jako jediný má přístup ke zdrojákům a právo je upravovat). Aneb nejsem tak bohatý, abych si mohl kupovat levné věci.
Máte pravdu, se zdrojovými kódy
a máte pravdu s vlastním hardware v odůvodněných případech.
Znám ale mnoho projektů, které řeší vlastní servery a přitom by mohli laciněji a často trochu paradoxně i spolehlivěji běžet v cloudu.
Licence, pod kterou vám autor umožní dílo užívat, by měla zejména umožňovat zásahy do díla vámi nebo jinou stranou, a také by měla umožňovat dílo šířit dále. Mnoho uzavřených licencí např. neumožňuje vytvořit více než dvě kopie – hlavní provozní a zálohu.
No ja osobne nemam problem s tym, ze ak si chce klient robit vlastne zasahy do diela, ktore mu dodam – potom samozrejme neberiem zodpovednost za jeho dalsiu funkcnost.
Ohladom sirenia diela uz je moj postoj jednoznacne iny. V tomto pripade totiz dielo je vlastne moje know-how a moje myslienkove pochody pretavene do zdrojovych kodov. Prave preto som proti tomu aby klient lubovolne siril dodane dielo(pokial samozrejme nie je dohodnute inak).
Ide o to ze ked si kupite mercedes, tak k nemu nedostanete kompletnu dokumentaciu vyrobnych postupov a cele know-how firmy s tym, ze ich mozete lubovolne sirit a pouzivat.
To iste je ked napr. spravim E-shop, alebo nejaky portal, tak klient skratka plati iba za ten dodany vyrobok. Skratka tak ako zaplati za auto, ktore moze lubovolne pouzivat, tak zaplati za software, ktory moze pouzivat. To ze sa da kopirovat a nasadit niekde inde je iba vlasnost softwaru ako takeho.
Tolko moj nazor na vec. Software je komodita ako kazda ina…
Jo, to s tim prirovnanim k autaku znam, a povazuju za peknou blbost. Srovnavas totiz nesrovnatelne! Zakaznik koupil tvoje zdrojaky, ne? Jednou ti uz za ty tve myslenkove pochody zaplatil, a ty zdrojaky (nebo aplikace) mu patri. Kdyz ty same zdrojaky chce jinej clovek, nemusis je vyvijet znova. Mezi vyvojem, a skopirovanim je sakra rozdil! Vyvoj muze byt drahej, a nekdo te za to musi zaplatit. Skopirovani hotoveho dila je prakticky bez nakladu…
A pokud jde o auta: koncovej zakaznik si nekupuje auto s vyrobnim postupem, aby jej mohl skopirovat a dat nekomu jinemu. Kdyz si ovsem firma A zaplati vyvoj auta (nebo nektere soucastky) u jine firmy B, firma A dostane pak od firmy B kompletni vyvojovou dokumentaci s popisem vyrobniho postupu, a muze si s ni delat co chce. Treba odevzdat kopii jine firme C, ktera to auto pro nej bude vyrabet. Takhle to je, a to rikam jako clovek ktery zrovna zakaznickej vyvoj automobilu a jejich komponentu dela. Pochopitelne, opet neco jineho je, kdyz si firma jenom objedna hotovou soucatku, tam si neplati za vyrobnej postup, nybrz za hotove kusy. V nich je ovsem ten vyvoj zohlednenej, ovsem jenom jednou! Proto jednotkova cena u zakazky 10 kusu je jina, nez jednotkova cena u zakazky na milion kusu…
No mozno to prirovnanie s autom nie je uplne na mieste, ale zober si napriklad taku automobilku Morgan – ti robia len auta na zakazku. Ked u nich kupis auto, tak sa stanes jeho vlastnikom, ale urcite k nemu nedostanes vyrobne plany.
No ale v tvojom pripade si firma A dala vypracovat koncepciu tvorby auta a nie auto na mieru. Tak isto aj software si mozes dat vypracovat na to aby si ho dalej predaval(v tom pripade kupujes myslienkove postupy a know-how), alebo kupujes software za ucelom pouzivania – napr. chcem Eshop aby som predaval.
Ja som narazal viac-menej na mensie projekty. Pri velkych informacnych alebo bankovych systemoch je situacia samozrejme trochu ina a aj sa pohybuju v inych cenovych relaciach. Tam si klient to know-how aj zaplati.
P.S: Netvrdim o sebe ze som najvacsi genius a moje zdrojaky maju nevycislitelnu hodnotu. Len som vyjadril svoj nazor na vec.
Ad „Software je komodita ako kazda ina…“
Právě že není – software se dá nekonečněkrát kopírovat, aniž by utrpěl na kvalitě nebo to bylo drahé – v tom se zásadně liší od hmotných výrobků a většiny služeb.
U softwaru proto dává větší smysl založit obchodní model na službách – a tyto služby prodávat za férovou cenu, která pokryje náklady dodavatele – než účtovat za licence a pak stavět nějaké umělé bariéry proti kopírování.
Článek sem ani nedočetl protože mi přijde ujetý. Webový software je licencovaný různě, často je licencovaný na doménu. To je přece logucké, když vývojář stráví měsíce vývoje aplikace, tak ji přece nebude rozdávat zadarmo, musí z něčeho žít. Zálohovat web můžete, můžete i zasahovat do kódu (čímž teda přijdete o záruku), ale nesmíte tu stejnou aplikaci použít na XY webech. To mi přijde fér a správné. V případě GPL software jde buďto o nadšenecký studentský projekty a nebo o něco za čím stojí komunita. Takový soft není špatný, ale je to často slepenec, který se stává ještě větším slepencem když ho vezme nějaký „vývojář“ a amatérsky upraví tak aby to nějak vyhovovalo požadavkům klienta. Což je víc než častý případ. Je na každým čemu bude důvěřovat, jestli otevřenosti a nebo zavřenosti. To samo o sobě nic neříká o kvalitě programu ani o tom jestli ten kdo s ním manipuluje se nás chystá natáhnout nebo ne. Obojí se dá, třeba tím že udělá práci za 2 hodiny, ale naúčtuje si třeba 6 tisíc. Takových se taky najde hromada.
Tenhle článek je fakt zmatený bulvární výkřik do tmy. Vemte vidle a jdeme upálit zlou čarodějnici.
Ad „Je na každým čemu bude důvěřovat, jestli otevřenosti a nebo zavřenosti. To samo o sobě nic neříká o kvalitě programu…“
Pak ale není důvod důvěřovat uzavřenému softwaru – i kdyby se člověk rozhodl, že bude „důvěřovat uzavřenému“, nic mu nebrání se na svobodný software dívat jako na uzavřený – to že jsou někde na Internetu dostupné zdrojáky ho vůbec nemusí trápit – ať se chová, jako by tam nebyly, když o ně nestojí.
Dobrý večer, vážení kolegové,
těší mě, že jsem vzbudil jistou kontroverzi, ale všimněte si, že některým Vašim názorům neodporuji.
Například nemám nic proti tomu si raději najmout na vývoj SW firmu, než použít nějaký existující opensource balík. Pokud si však najmu firmu, chci abych s jejím produktem mohl zacházet jako s opensource a jsem si vědom rizik ale i výhod.
Dokonce to není ani nic proti tomu, že si k software mohu od firmy, která ho vyvinula koupit i SLA smlouvu na jeho údržbu.
Pokud si však koupím vendor lock, tak mě ani SLA smlouva nezachrání. Jde o to, aby firma šla změnit, pokud nevyhovuje. Nejde o to, aby se v kódu rýpalo deset různých firem/lidí.
Díky za pozornost.
Mam dojem, ze vsichni mluvime o tom samem, jen z ruznych uhlu pohledu. Pokud mam relativne uzkoprofilovy software, ktery vyuziva par zakazniku nebo je dokonce na miru, tak je jednoznacne nutne z hlediska bezpecnosti mit k dispozici zdrojove kody. To ovsem neznamena, ze nemusim platit za licenci, za podporu, za dalsi vyvoj. Naopak. Je to jen bezpecnostni opatreni.
Pokud mam obavy o sve dusevni vlastnictvi (IP), resi se problem u velkych zakazek s pomoci takzvanych „escrow tapes“, ktere jsou ulozeny u „escrow agent“. Escrow tape obsahuje cely software vcetne prostredi nutneho k zkompilovani/sestaveni aplikace. Escrow agent je specializovana nezavisla firma, ktera vyda escrow tape uzivateli v pripade, kdy dojde ke splneni predem definovanych podminek, napr. ukonceni podpory, vyvoje, nesplneni nasmlouvanych pozadavku nebo krach autora.