Příspěvky

1

Studium a uplatnění / Re:Pojištění na škody při výkonu práce OSVČ

« kdy: 13. 07. 2025, 21:03:49 »

no ty brďo 5 let se táhnoucí soud, ty náklady na znalce, které navrhujete, že převezmu já atd - třeba já bych se bál, že se to na mě podepíše, ale třeba jiní s tím budou v pohodě

to bych tedy spíš zkusil s nimi jít na nějakou "rychlou" dohodu: můj právník by na ně šel s materiálama, které jsem výše doporučil sbírat, tzn. systém jste měli v shitovém stavu, dokumentace žádná, já jsem se snažil "lege artis" fungovat co nejlépe to šlo, postupy/specifikace jste znali a schválili, workshop jsme na to dělali, testovalo se to, o rizicích jste informace dostali, atd atd, ale bohužel přesto přes všechno shit happened, prokažte podíl mé chyby nebo neprofesionality, za mě vidím rozhodující podíl viny u vás atd ...

když by tu dohodu vzali (asi bych jim musel (podle doporučení právníka) nějakou mrkev strčit), tak uff

když ne, tak potom ten 5 let se táhnoucí soud, jak píšete

2

Studium a uplatnění / Re:Pojištění na škody při výkonu práce OSVČ

« kdy: 13. 07. 2025, 16:34:16 »

vůči pojištění bych měl také rezervovaný postoj

zodpovědnost za úmyslné škody IMHO omezit nelze - těžko bude jakýkoliv právní systém na světě chtít chránit někoho, kdo bude něco úmyslně páchat (např. jak zmíněno si nakrade za 100M)

nicméně zodpovědnost za neúmyslné škody IMHO by (konzultujte s právníkem pro danou jurisdikci) smluvně omezit jít mělo - například s poukazem na nedokumentovaný systém a jeho nejasné souvislosti, na kterém se má dělat nějaká práce - potom by mělo být snad i v pořádku, že zbývající riziko si ponese ten, kdo ten systém do tohoto nedobrého stavu dostal (jeho vlastník). O toto omezení odpovědnosti bych se určitě snažil.

ale hlavně bych se snažil snižovat riziko (eliminovat na nulu jej bohužel nelze) vlastním konáním, například:

dodržovat dobrou IT praxi a taky trochu papírovat okolo toho: být transparentní, psát, co se bude dít, specifikovat, jak bude daná SW změna provedena a co znamená, upozornit na rizika, kterých se obávám, udělat okolo toho workshop, nechat si potvrdit písemně, změnu řádně otestovat (plus nechat otestovat a poskytnout maximální součinnost) atd

zkrátka zapojit více lidí, což kromě rozprostření rizika může pomoci i reálně (například si někdo může "vzpomenout", že tohle takhle nejde, protože ..., reviewer může vidět něco, co jste přehlédl, tester může udělat tak "debilní" test, který by vás nenapadl atd.)

pro akce typu backup, restore, switchover si vyžádat existující scénář/metodiku/script. Pokud neexistují (opět důkaz nedobrého stavu), tak vytvořit, otestovat, rozeslat, žádat o komenty, nechat si schválit, jet podle toho, plus pokud možno aby u toho byly čtyři oči atd. Opět toto může pomoci i reálně: jet podle "něčeho" je vždy méně rizikové než ad-hoc vařit z vody. Vytvořený scénář/metodiku/script dát do version control (jako by to byl zdroják), aby bylo vidět, co tam kdo kdy a proč měnil atd

nenechat se dohnat do stresu a přetížení. Např. jednou jsem vyvíjel migrační script s mnoha TRUNCATy a vedle toho měl otevřené SQL okno na prod. Kdybych byl trochu unavenější, mohl jsem ten script omylem pustit na produ. Nastěstí se nestalo. Lepší ale třeba dělat na produ z jiné mašiny, potom by takovýto omyl neměl nastat ani teoreticky.

dodržovat všechny cyber-security předpisy (čím dál důležitější)

v práci nechlastat, nefetovat, nečumět na porno, nehrát žádné hry atd - to je ale snad samozřejmé.

Poučné:

https://www.irishtimes.com/business/financial-services/ulster-bank-counts-the-cost-of-catastrophic-it-meltdown-1.530340

3

Server / Re:Oboustranná synchronizace v Debianu

« kdy: 23. 06. 2020, 20:09:21 »

Pokud hledáte něco maličkého, co umí synchronizovat oboustranně, tak zkuste kouknout na tohle: https://github.com/Fitus/Zaloha.sh

Nemusí se to ani instalovat. Je to shellový skript, co používá find, sort awk a copy.

Normálně je jeden adresář source a druhý backup. Má to ale dvě optiony, které myslím potřebujete: --revUp způsobí, že když je na backupu novější file než na source, tak ho to zkopíruje z backupu na source. --revNew způsobí, že když máte na backupu file novější než poslední běh a na sourcu ten file není, tak ho to taky zkopíruje na source. Ono si to totiž pamatuje svůj poslední běh, používá to fily v podadresáři .Zaloha_metadata na backupu.

4

Server / Re:Přenos velkého množství dat po síti

« kdy: 24. 01. 2020, 22:19:01 »

Již to tu bylo naznačeno: Co to provést maximálně jednoduše a šetrně k síti:

Pořídit nějakou storage, na kterou se to vejde (například HDD s několika TB a USB 3.2 stojí pár tisíc (SSD by bylo dražší, samozřejmě)). Tuto storage potom připojit ke zdrojovému serveru a lokálně nasynchronizovat data, například tímto jednoduchým programem: https://www.ostechnix.com/how-to-synchronize-files-and-directories-using-zaloha-sh/

Potom tu storage fyzicky přenést, připojit k cílovému serveru a opět lokálně nasynchronizovat.

Výhodou je, že budeš mít další kopii dat, kterou můžeš uložit na nějakou třetí lokaci. Navíc pokud tu samou storage použiješ při příštím přenosu, bude to rychlejší, protože se budou synchronizovat pouze nové/změněné soubory.

Integritu dat možno řešit ex-post. Na obou serverech pustit pomocí find-u výpočet SHA256 všech souborů a výsledek uložit do csv souboru, kde budou cesty k souborům a jejich SHA256. Tyto dva "malé soubory" potom stáhnout na jeden stroj a tam porovnat diff-em ...