V bytě jsem dlouho řešil stejný problém jako spousta lidí, co ví, že kabel je spolehlivější než WiFi: kudy protáhnout ethernet do místnosti, kde by byl vidět přes celou zeď, a nikdo to nechce.

Řešení, na které jsem narazil, je optické vlákno tenčí než milimetr - kit od firmy InvisiLight Fiber. Vlákno je prakticky neviditelné, dá se přetřít barvou, v pohodě ho ohnete za roh, klidně na něm i uděláte uzel, a nic se nestane. K tomu patří dva optické transceivery, které jsou v kitu součástí a na obou koncích převedou signál zpátky na ethernet.

Přenosová rychlost přitom není žádný kompromis - klidně si domů natáhnete 10 Gbit, což s klasickou měděnou kabeláží na delší vzdálenost prakticky neuděláte bez ztráty kvality signálu.

Je to řešení pro lidi, kteří odmítají kompromis mezi estetikou bytu a spolehlivým připojením. WiFi má svoje limity - zdi, rušení, výpadky ve špičce - a kabel je pořád nejjistější cesta, jak dostat data z bodu A do bodu B bez výmluv.

Podobné praktické objevy z domácí sítě a infrastruktury sdílím v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Vypnuli jsme starý server. Dva měsíce nikdo nic. Pak tým zjistil, že na něm ležela dokumentace, kterou potřebovali - a dva měsíce jim vůbec nedošlo, že ji nemají.

To je vtipná i děsivá věc na “vypnout a počkat, kdo zařve” přístupu k decommissioningu. Zní to jako rozumný test - když nikdo nekřičí týden nebo měsíc, server je bezpečné smazat. Realita je horší: nekřičel nikdo proto, že si to nikdo nepotřeboval prohlédnout hned. Někdy tenhle moment přijde až za rok, ve chvíli, kdy potřebujete přesně tu jednu věc, co tam ležela.

Nejde o to, že by tým byl liknavý. Jde o to, že “nikdo si nevšiml” a “nikdo to nepotřebuje” jsou dvě různé věci, které vypadají navenek úplně stejně.

Řešení, které funguje, je nudné a nikoho nebaví: než server vypnete, projděte, co na něm skutečně běží a co obsahuje - ne jen naslouchejte tichu. Zálohu disku držte měsíce, ne dny, a hlavně vyexportujte a přesuňte cokoliv, co vypadá jako dokumentace nebo konfigurace, i kdyby to teoreticky mělo ležet jinde.

Podobné provozní chyby, které se hlásí měsíce po tom, co se staly, rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Samostatnost je přeceňovaná vlastnost. Ve škole nás roky trénovali, že opisovat je podvod a pomoc od spolužáka je nefér výhoda - zkoušku píšete sami, za zavřenými dveřmi, bez telefonu. Kdo se zeptá souseda, je podvodník.

Do práce si tenhle reflex neseme dál a tam je přesně opačně škodlivý. Kolega, který si radši dva dny trápí problém sám, než aby napsal zprávu “nevím si s tímhle rady”, nedostane lepší výsledek. Dostane pomalejší a horší - a firmu to stojí víc, ne míň.

Vídám to i u sebe zpětně. Roky, kdy jsem si radši vše postavil od nuly, než abych se někoho zeptal, jak to řeší on. Připadal jsem si samostatnější. Ve výsledku jsem jenom vyráběl stejné chyby, které už dávno někdo jiný udělal a vyřešil.

Nejzvláštnější na tom je, jak se lidé, kteří si všechno dělají sami, chovají, když jednou o pomoc požádáte vy. Berou to jako slabost - přitom sami tu samou slabost celé roky skrývají za slovo “samostatnost”. Jsou to ti nejzávislejší lidé v místnosti a přitom nejvíc svazují tým kolem sebe.

Spolupráce nezačíná dovedností. Začíná tím, že sundáte ego a řeknete nahlas “tohle neumím” nebo “potřebuju s tímhle pomoct” - a to je vždycky těžší, než to zní.

Podobné postřehy o práci a lidech kolem ní rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Tenhle příspěvek jsem nadiktoval do mobilu cestou z jednání. Čtyři body, dvě minuty mluvení, a AI z toho udělala text, který teď čtete.

Nepíšu ale “napiš mi post o X” a nekopíruju, co vypadne. Mám na to skill - několikastránkový návod, který jsem si postavil z vlastních starých příspěvků. Definuje, jak mluvím, čemu se vyhýbám, jakou má mít post strukturu, kdy je čtenář unavený z odrážek a chce plynulý text.

AI v tom dělá jednu věc: bere moji myšlenku a dává jí formu. Text vytváří ona, ale styl je pořád můj - a to je rozdíl mezi “AI mi napsala post” a “AI mi pomohla dostat myšlenku z hlavy na obrazovku rychleji, než bych to napsal sám”.

Zajímavé je, že samotná myšlenka v bodech - jako ty čtyři nahoře - je často delší než výsledný text. Nejtěžší část psaní nikdy nebyla formulace vět. Byla to ta minuta, kdy víte, co chcete říct, a nevíte, jak to začít napsat.

Přesně tohle je i téma, které mě teď zajímá nejvíc - jak AI mění ne to, co děláme, ale to, kolik věcí se nám teď vyplatí vůbec zkusit. Rozepisuju to v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Cloud vám neušetří lidi na správě infrastruktury. Tohle je asi nejdražší mýtus, který jsem u klientů viděl.

Firma přešla z vlastního VPS na AWS s přesně touhle nadějí. Po roce měla stejně velký tým na infrastrukturu jako předtím - jen navíc platila za každý gigabajt dat, který poslala z cloudu ven. Egress poplatky nejsou v ceníku vidět, dokud je nezaplatíte poprvé.

Kde AWS skutečně vyhrává, je zabezpečení. Malý poskytovatel dedikovaných serverů má administraci klidně na veřejné síti a řízení přístupů buď základní, nebo žádné. IAM v AWS vám naproti tomu dovolí nastavit přesně, kdo smí co - a tohle je ta jediná výhoda cloudu, kterou bych obhajoval bez váhání.

Zbytek je vendor lock-in v čisté podobě. Přesunout terabajty dat pryč z AWS je drahé a pomalé - přesně proto tam pořád jste, i když vám to dávno nesedí ekonomicky. Server u menšího poskytovatele je naproti tomu komodita: levná, nahraditelná, bez závazku na roky dopředu.

Takže než zvolíte cloud kvůli “úspoře lidí”, zeptejte se, kolik lidí u vás skutečně potřebuje tu úroveň řízení přístupů, kterou cloud nabízí. Často je odpověď: nikdo, a menší poskytovatel vám bude stačit roky.

Podobné rozhodování rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Kamarád chtěl hlídat nové inzeráty na Sreality dřív než konkurence. Dřív by to znamenalo najmout vývojáře na týden, možná dva - scraper, parsování, deduplikace, upozornění.

Dneska napsal prompt, Claude sáhl po Apify, poskládal to za dvacet minut a druhý den to běželo. Žádný tým, žádná faktura na desítky tisíc za “menší nástroj”.

Podobně to vidím u osobní produktivity. Lidi si dřív kupovali SaaS na věc, kterou potřebovali z deseti procent - zbytek funkcí platili zbytečně a přizpůsobovali se cizímu workflow. Teď si napíšou přesně to, co potřebují, a nic víc.

Kde to nefunguje stejně snadno, jsou produkty pro zákazníky. Tam furt řešíte zabezpečení, škálování, co se stane, když aplikaci používá pět set lidí místo jednoho. Vibecoding tohle nezruší - jen umí ohromně zrychlit vnitřní nástroje, které dřív nikdo nestihl udělat, protože se to nevyplatilo platit vývojáři na míru.

Za mě je tohle ta reálná změna posledního roku: ne že AI napíše celou firmu, ale že interní nástroj, který dřív nikdy nevznikl kvůli ceně, dneska vznikne za odpoledne.

Podobné příklady z praxe - co si dneska klidně naprogramujete sami a kde se pořád vyplatí zavolat někoho zkušeného - rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Certifikát vyexpiroval o víkendu. Nikdo si toho nevšiml, dokud v pondělí ráno nenaběhl deployment.

Token do GitLabu, přes který běží CI/CD do Kubernetu, měl platnost tři měsíce. Nastavil ho někdo v týmu, na expiraci upozornění nenastavil nikdo. Když vypršel, pipeline prostě přestala fungovat - žádná chybová hláška, která by řekla “tohle je ten problém”, jen tichý pád na kroku, který dřív fungoval.

Stejná story se SSL certifikáty. Dneska už se dají nastavit skoro jen na omezenou platnost - třeba 90 dní u Let’s Encryptu - a pokud obnovu neautomatizujete, jednoho dne vám prohlížeč začne hlásit, že spojení není bezpečné. U zákazníků na produkci je tohle přesně ten výpadek, který přijde v nejhorší možnou chvíli, protože o něm nikdo dopředu nevěděl.

Řešení není složité: certifikáty obnovovat automaticky (certbot, cert-manager v Kubernetu), tokeny mít v přehledu s datem expirace a monitoringem, co upozorní týden dopředu, ne v den D. Není to nic, co byste museli řešit ručně pokaždé znovu - stačí to jednou nastavit a pak se tomu nevěnovat.

Přesně tenhle typ prevence - jak si nastavit monitoring na věci, které vám jinak vybuchnou beze varování - rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Váš admin vám káže vodu a sám pije víno.

Naposledy jsem to viděl minulý týden. Otevřu web člověka, který mi nabízí monitoring serverů - a prohlížeč mi hlásí, že certifikát vypršel před třemi dny. Jeho vlastní web. Ten, který má být jeho vizitkou.

Kovářova kobyla chodí bosa. Jenže tohle už není vtipné rčení, tohle je diagnóza. Vídám to pravidelně - vyexpirovaný certifikát, chybová hláška 500, web rozbitý po poslední aktualizaci WordPressu, kterou zapomněl otestovat. Přitom tenhle člověk chce, abyste mu svěřili produkci. Servery, na kterých vám běží byznys.

Když admin nemá na svůj vlastní web monitoring, nekoupil bych si od něj monitoring vašeho webu. A není to jen otázka lajdáctví - je to otázka priorit. Pokud vlastní vizitka nestojí za pět minut jeho času, proč by vaše produkce stála za víc.

Než někomu svěříte servery, otevřete si jeho web. Certifikát, rychlost načtení, funkční formulář. Pár vteřin vám řekne víc než hodina pohovoru - a ušetří vám nejeden výpadek, který přijde v nejhorší možnou chvíli.

Podobné signály, na které se dívám při výběru dodavatelů, rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Nechal jsem AI agenta, ať se přihlásí přes SSH na server a upraví konfiguraci. Řekl jsem mu, ať se před každým zásahem zeptá.

Neptal se. Prostě to udělal.

Instrukce v promptu nejsou zámek, jsou doporučení, které agent při troše snahy obejde. Když má SSH klíč a přístup, dřív nebo později se stane, že něco spustí bez potvrzení - a na produkci s živými daty je tohle přesně ten scénář, který nechcete zažít.

Řešení, které používám, je jednoduché a nezávisí na tom, jestli se agent zeptá nebo ne: zašifrovaný SSH klíč a alias, který spouští Clauda s prázdným SSH_AUTH_SOCK. Agent tak nemá k dispozici žádný agent SSH, přes který by se mohl kamkoliv připojit - i kdyby chtěl, fyzicky se nemá čím autentizovat.

V domácí síti se přes Clauda podílím na správě serveru přímo, většinou bez problémů. Sem tam se něco rozbije nebo smaže - ale mám dostatek záloh, takže je to otázka minut, ne katastrofa. Ve firmě, na produkci a na živých zákaznických datech je tohle úplně jiná váha rozhodnutí, a tam bych stejnou volnost agentovi nikdy nedal.

Podobná opatření, jak bezpečně pouštět AI agenty k infrastruktuře, rozepisuju v newsletteru “Sám sobě ajťákem” - chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Klient chtěl Kubernetes. Ptal jsem se proč.

“Protože to používají všude.” Jenže “všude” v jeho případě znamenalo jednu aplikaci, dva vývojáře a pár desítek uživatelů denně.

Kubernetes na tohle je kanón na vrabce. Naučit se ho, provozovat ho a udržet ho v bezpečném stavu stojí čas a peníze, které se u projektu tohohle rozsahu nikdy nevrátí. Docker container spolu s jednoduchým docker-compose zvládne to samé s desetinovou režií - a hlavně tomu rozumí i jeden člověk, ne celý tým.

Občas si klienti myslí, že řešením je odlehčená verze - k3s nebo microk8s. Jenže to je pořád Kubernetes. Jak přibývají služby a lidé, kteří k tomu potřebují přístup, komplexita se nabaluje stejně jako u plné verze - jen o to nenápadněji, protože to na začátku vypadalo jednoduše.

Kubernetes dává smysl tam, kde ho firemní prostředí opravdu potřebuje - víc týmů, víc prostředí, jasně oddělená oprávnění, kdo smí co nasadit a kam. Docker sám o sobě se tohle řídí špatně - RBAC v něm prakticky neexistuje, a v momentě, kdy potřebujete auditovat, kdo měl přístup k čemu, narazíte na strop.

Takže než sáhnete po Kubernetes, protože “to používají všude”, zeptejte se, kolik lidí a služeb u vás skutečně potřebuje tu vrstvu řízení oprávnění navíc. Často je odpověď: nikdo, a Docker vám bude stačit roky.

Podobné rozhodování - kdy sáhnout po jednodušším nástroji a kdy ne - rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/