Automatizace výměny disku pomocí Ansible

Ahoj všichni. Pracuji jako vedoucí systémový administrátor v OK a zodpovídám za stabilní provoz portálu. Chci mluvit o tom, jak jsme postavili proces automatické výměny disku a jak jsme z tohoto procesu vyloučili správce a nahradili ho botem.

Tento článek je jakýmsi přepisem představení na HighLoad+ 2018

Vytvoření procesu výměny disku

Nejprve pár čísel

OK je obří služba, kterou využívají miliony lidí. Obsluhuje ho asi 7 tisíc serverů umístěných ve 4 různých datových centrech. Na serverech je více než 70 tisíc disků. Pokud je naskládáte na sebe, získáte věž s výškou více než 1 km.

Pevné disky jsou součástí serveru, která selhává nejčastěji. Při tomto objemu musíme vyměnit cca 30 disků týdně a tento postup se stal nepříliš příjemnou rutinou.

Incidenty

V naší společnosti jsme zavedli plnohodnotný incident management. Každý incident zaznamenáme do Jiry a poté ho řešíme a analyzujeme. Pokud měl incident na uživatele vliv, tak se určitě sejdeme a promyslíme, jak v takových případech reagovat rychleji, jak snížit dopad a samozřejmě jak zabránit opakování.

Skladování není výjimkou. Zabbix sleduje jejich stav. Sledujeme zprávy v Syslogu na chyby zápisu/čtení, analyzujeme stav HW/SW raidů, sledujeme SMART, počítáme opotřebení SSD.

Jak se dříve měnily disky

Když se v Zabbixu spustí spoušť, v Jira se vytvoří incident a automaticky se to dostane na příslušné inženýry v datových centrech. Děláme to se všemi HW incidenty, tedy těmi, které vyžadují nějakou fyzickou práci na zařízení v datovém centru.
Inženýr datového centra je osoba, která řeší problémy související s hardwarem, je odpovědná za instalaci, údržbu a demontáž serverů. Po obdržení lístku se inženýr pustí do práce. V diskových regálech si vyměňuje disky sám. Pokud však nemá přístup k požadovanému zařízení, obrátí se technik na správce systému s žádostí o pomoc. V první řadě je potřeba vyjmout disk z rotace. Chcete-li to provést, musíte provést potřebné změny na serveru, zastavit aplikace a odpojit disk.

Za provoz celého portálu během pracovní směny odpovídá službu konající správce systému. Vyšetřuje incidenty, provádí opravy, pomáhá vývojářům s drobnými úkoly. Nezabývá se pouze pevnými disky.

V minulosti si inženýři datových center povídali se správcem systému. Inženýři poslali odkazy na lístky Jira, administrátor je prošel, vedl si protokol o práci v nějakém sešitu. Ale pro takové úkoly jsou chaty nepohodlné: informace tam nejsou strukturované a rychle se ztrácejí. Ano, a administrátor se mohl jednoduše vzdálit od počítače a nějakou dobu nereagovat na požadavky a inženýr stál u serveru s balíčkem disků a čekal.

Nejhorší však bylo, že správci neviděli celý obrázek: jaké diskové incidenty existují, kde by potenciálně mohl nastat problém. Je to dáno tím, že veškeré HW incidenty dáváme inženýrům. Ano, na administračním panelu bylo možné zobrazit všechny incidenty. Ale je jich hodně a správce se podílel jen na některých.

Kromě toho inženýr nemohl správně stanovit priority, protože neví nic o účelu konkrétních serverů, o distribuci informací mezi disky.

Nový postup výměny

První věc, kterou jsme udělali, bylo přesunout všechny diskové incidenty na samostatný typ „HW disk“ a přidat do něj pole „název zařízení bloku“, „velikost“ a „typ disku“, aby se tyto informace uložily do tiketu a ne musí neustále chatovat.

Dohodli jsme se také, že v rámci jednoho incidentu vyměníme pouze jeden disk. To značně zjednodušilo proces automatizace, sběr statistik a práci do budoucna.

Navíc přibylo pole „odpovědný správce“. Automaticky je zde nahrazen správce služebního systému. To je velmi výhodné, protože nyní inženýr vždy vidí, kdo je zodpovědný. Není třeba chodit do kalendáře a dívat se. Právě toto pole umožnilo na administrátorském dashboardu zobrazovat vstupenky, ve kterých může být potřeba jeho pomoci.

Aby všichni účastníci měli z inovací maximální užitek, vytvořili jsme filtry a dashboardy a řekli o nich klukům. Když lidé změnu pochopí, nedistancují se od ní jako od něčeho zbytečného. Je důležité, aby technik znal číslo racku, kde je server umístěn, velikost a typ disku. Administrátor musí především pochopit, o jakou skupinu serverů se jedná, jaký vliv to může mít při výměně disku.

Přítomnost polí a jejich zobrazení je pohodlné, ale to nás nezachránilo od nutnosti používat chaty. K tomu jsme museli změnit pracovní postup.

Kdysi to bylo takto:

Dnes takto inženýři pokračují v práci, když nepotřebují pomoc správce.

První věc, kterou jsme udělali, bylo zavedení nového stavu Vyšetřovat. Lístek je v tomto stavu, když se inženýr ještě nerozhodl, zda bude potřebovat správce nebo ne. Prostřednictvím tohoto stavu může technik předat lístek správci. Tímto stavem navíc označíme vstupenky, když je nutná výměna disku, ale samotný disk není na místě. To se děje v případě CDN a vzdálených míst.

Přidali jsme také stav Připravený. Lístek se do něj přenese po výměně disku. To znamená, že vše již bylo provedeno, ale HW / SW RAID je synchronizován na serveru. To může trvat poměrně dlouho.

Pokud je do práce zapojen správce, schéma se trochu zkomplikuje.

Mimo stav Otevřená Vstupenku může přeložit jak správce systému, tak technik. ve stavu Probíhá administrátor odebere disk z rotace, aby jej technik mohl jednoduše vytáhnout: zapne podsvícení, odpojí disk, zastaví aplikace v závislosti na konkrétní skupině serverů.

Lístek je pak přeložen do Připraveno ke změně: Toto je signál pro inženýra, že disk lze vytáhnout. Všechna pole v Jira jsou již vyplněna, inženýr ví, jaký typ a velikost disku. Tyto údaje zadává buď o předchozím stavu automaticky, nebo administrátor.

Po výměně disku se tiket přenese do stavu Změněno. Zkontroluje se, zda byl vložen správný disk, provede se rozdělení, spustí se aplikace a spustí se některé úlohy obnovy dat. Lístek lze také převést do stavu Připravený, v tomto případě zůstane odpovědný správce, protože spustil disk v rotaci. Kompletní schéma vypadá takto.

Přibývání nových oborů nám hodně usnadnilo život. Kluci začali pracovat se strukturovanými informacemi, bylo jasné, co je potřeba udělat a v jaké fázi. Priority se staly mnohem relevantnějšími, protože je nyní nastavuje správce.

Chaty nejsou potřeba. Administrátor samozřejmě může inženýrovi napsat „zde potřebujete vyměnit rychleji“ nebo „už je večer, budete mít čas to vyměnit?“. Ale o těchto otázkách už nekomunikujeme denně v chatech.

Disky se začaly měnit po dávkách. Pokud administrátor přišel do práce trochu dříve, má volno a zatím se nic neděje, může připravit řadu serverů na výměnu: vyplnit pole, odebrat disky z rotace a přenést úkol na inženýra. Technik přijde do datového centra o něco později, uvidí úkol, vezme si potřebné disky ze skladu a okamžitě je vymění. V důsledku toho se náhradový poměr zvýšil.

Získané zkušenosti při budování Workflow

• Při vytváření procedury musíte sbírat informace z různých zdrojů.
  Někteří z našich administrátorů nevěděli, že si technik vyměňuje disky sám. Někteří lidé si mysleli, že MD RAID udržovali inženýři v synchronizaci, i když k němu někteří z nich ani neměli přístup. Někteří přední inženýři to dělali, ale ne vždy, protože proces nebyl nikde popsán.
• Postup by měl být jednoduchý a srozumitelný.
  Pro člověka je těžké udržet si v hlavě mnoho kroků. Nejdůležitější sousední stavy v Jira by měly být umístěny na hlavní obrazovce. Můžete je přejmenovat, například In progress nazýváme Připraveno ke změně. A zbytek stavů je možné skrýt v rozbalovací nabídce, aby z nich nebolely oči. Ale je lepší lidi neomezovat, dát jim příležitost k přechodu.
  Vysvětlete hodnotu inovací. Když lidé pochopí, lépe přijmou nový postup. Bylo pro nás velmi důležité, aby se lidé celý proces neproklikávali, ale sledovali. Pak jsme na tuto automatizaci stavěli.
• Počkejte, analyzujte, pochopte.
  Sestavení postupu, technická realizace, schůzky a diskuse nám zabraly zhruba měsíc. A pro realizaci - více než tři měsíce. Viděl jsem, jak lidé pomalu začínají používat inovace. V raných fázích bylo hodně negativity. Bylo to ale zcela nezávislé na samotném postupu, jeho technickém provedení. Například jeden administrátor nepoužil Jiru, ale plugin Jira v Confluence a některé věci pro něj nebyly dostupné. Ukázali jsme mu Jira, admin zvýšil produktivitu jak v obecných úlohách, tak ve výměnách disků.

Automatizace výměny disku

Několikrát jsme přistupovali k automatizaci výměny disků. Už jsme měli vývoj, skripty, ale všechny fungovaly buď v interaktivním nebo manuálním režimu, vyžadovaly spuštění. A až po zavedení nového postupu jsme si uvědomili, že je to přesně to, co potřebujeme.

Protože je nyní proces výměny rozdělen do fází, z nichž každá má svého vykonavatele a seznam akcí, můžeme povolit automatizaci ve fázích a ne všechny najednou. Například nejjednodušší fázi - Ready (kontrola RAID / synchronizace dat) lze snadno delegovat na bota. Když se bot trochu naučí, můžete mu dát zodpovědnější úkol – uvést disk do rotace atd.

Nastavení Zoo

Než budeme mluvit o robotovi, pojďme si udělat krátkou prohlídku naší instalační zoo. Za prvé je to kvůli gigantické velikosti naší infrastruktury. Za druhé, pro každou službu se snažíme vybrat optimální hardwarovou konfiguraci. Máme asi 20 modelů hardwarových RAID, hlavně LSI a Adaptec, ale existují i ​​HP a DELL různých verzí. Každý řadič RAID má svůj vlastní nástroj pro správu. Sada příkazů a jejich výstup se může lišit verze od verze pro každý RAID řadič. Kde není použit HW-RAID, může být mdraid.

Téměř všechny nové instalace provádíme bez redundance disku. Snažíme se přestat používat hardwarové a softwarové RAID, protože naše systémy zálohujeme na úrovni datových center, nikoli serverů. Ale samozřejmě existuje mnoho starších serverů, které je třeba udržovat.

Někde jsou disky v RAID řadičích hozeny raw zařízení, někde se používají JBODy. Na serveru jsou konfigurace s jedním systémovým diskem, a pokud je třeba jej vyměnit, musíte server znovu spustit instalací operačního systému a aplikací a stejných verzí, poté přidat konfigurační soubory, spustit aplikace. Existuje také mnoho skupin serverů, kde se redundance neprovádí na úrovni diskového subsystému, ale přímo v aplikacích samotných.

Celkem máme přes 400 unikátních skupin serverů, na kterých běží asi 100 různých aplikací. Abychom pokryli tak obrovské množství možností, potřebovali jsme automatizační nástroj bohatý na funkce. Nejlépe s jednoduchým DSL, aby to podpořil nejen ten, kdo to psal.

Vybrali jsme Ansible, protože je bez agenta: nebylo potřeba připravovat infrastrukturu, rychlý start. Navíc je napsaný v Pythonu, který je v týmu akceptován jako standard.

Obecné schéma

Podívejme se na obecné schéma automatizace na příkladu jednoho incidentu. Zabbix zjistí, že selhal sdb disk, spustí se trigger a v Jira se vytvoří tiket. Administrátor se na to podíval, uvědomil si, že se nejedná o duplikát a ne o falešně pozitivní, to znamená, že je třeba vyměnit disk, a přenese tiket do Probíhá.

Aplikace DiskoBot napsaná v Pythonu pravidelně dotazuje Jiru na nové vstupenky. Všimne si, že se objevil nový lístek In progress, spustí se odpovídající vlákno, které spustí playbook v Ansible (to se provádí pro každý stav v Jira). V tomto případě se spustí Prepare2change.

Ansible přejde k hostiteli, odebere disk z rotace a prostřednictvím Callbacks nahlásí stav aplikaci.

Na základě výsledků robot automaticky změní tiket na Připraven ke změně. Inženýr obdrží upozornění a jde vyměnit disk, načež přenese lístek do Changed.

Podle výše uvedeného schématu se lístek vrátí k botovi, který spustí další playbook, přejde k hostiteli a uvede disk do rotace. Bot zavře lístek. Hurá!

Nyní si povíme něco o některých součástech systému.

Diskobot

Tato aplikace je napsána v Pythonu. Vybírá lístky od Jiry podle JQL. V závislosti na stavu tiketu se tento dostane k příslušnému handleru, který zase spustí Ansible playbook odpovídající stavu.

JQL a intervaly dotazování jsou definovány v konfiguračním souboru aplikace.

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

Například mezi tipy ve stavu Probíhá jsou vybrány pouze ty s vyplněnými poli Velikost disku a Název zařízení. Název zařízení je název blokového zařízení potřebného ke spuštění playbooku. Velikost disku je potřeba, aby technik věděl, jaká velikost disku je potřeba.

A mezi tipy se stavem Připraveno jsou vyfiltrovány tipy s popiskem dbot_ignore. Mimochodem, Jira labely používáme jak pro takové filtrování, tak pro označování duplicitních tiketů a sběr statistik.

V případě selhání playbooku Jira přiřadí štítek dbot_failed, aby jej bylo možné později vyřešit.

Interakce s Ansible

Aplikace komunikuje s Ansible prostřednictvím Ansible Python API. V playbook_executor předáme název souboru a sadu proměnných. To vám umožňuje ponechat projekt Ansible ve formě běžných yml souborů a nepopisovat jej v kódu Pythonu.

Také jméno blokového zařízení, stav tiketu a také callback_url, ve kterém je napevno zakódován problémový klíč, jsou do Ansible přenášeny přes *extra_vars* - používá se pro zpětné volání v HTTP.

Pro každé spuštění se vygeneruje dočasný inventář skládající se z jednoho hostitele a skupiny, do které tento hostitel patří, takže se použijí proměnné skupiny.

Zde je příklad úlohy, která implementuje zpětné volání HTTP.

Výsledek provádění playbooku získáme pomocí callaback(ů). Jsou dvou typů:

• Ansible plugin zpětného volání, poskytuje údaje o výsledcích provádění playbooku. Popisuje úkoly, které byly spuštěny, dokončeny úspěšně nebo neúspěšně. Toto zpětné volání je voláno, když playbook dokončí přehrávání.
• Zpětné volání HTTP pro získání informací během přehrávání playbooku. V úloze Ansible provedeme požadavek POST / GET na stranu naší aplikace.

Prostřednictvím HTTP callback(s) jsou předávány proměnné, které byly definovány během provádění playbooku a které chceme uložit a použít v dalších spuštěních. Tato data zapisujeme do sqlite.

Také přes HTTP callback zanecháváme komentáře a měníme stav tiketu.

HTTP zpětné volání

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

Stejně jako mnoho úkolů stejného typu jsme jej přesunuli do samostatného společného souboru a v případě potřeby jej zapnuli, aby se v playbookech neustále neopakoval. Zde se zobrazí adresa URL zpětného volání, ve které jsou chráněny klíč vydání a název hostitele. Když Ansible provede tento požadavek POST, bot pochopí, že přišel jako součást takového a takového incidentu.

A zde je příklad z playbooku, ve kterém jsme vysunuli disk z MD zařízení:

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

Tento úkol změní stav lístku Jira na „Připraveno ke změně“ a přidá komentář. Proměnná mdam_data také obsahuje seznam zařízení md, ze kterých byl disk odebrán, a parted_info obsahuje výpis oddílu z parted.

Když technik vloží nový disk, můžeme pomocí těchto proměnných obnovit výpis z oddílu a také dostat disk do md zařízení, ze kterých byl odstraněn.

Aktivní kontrolní režim

Zapnutí automatiky bylo děsivé. Proto jsme se rozhodli spustit všechny playbooky v režimu
suchý běh, ve kterém Ansible neprovádí žádné akce na serverech, ale pouze je emuluje.

Takové spuštění je spuštěno prostřednictvím samostatného modulu zpětného volání a výsledek provádění playbooku je uložen v Jira jako komentář.

Za prvé to umožnilo ověřit práci robota a playbooků. Za druhé, zvýšilo to důvěru administrátorů v bota.

Když jsme prošli validací a uvědomili jsme si, že je možné spustit Ansible nejen v režimu suchého běhu, vytvořili jsme v Jira tlačítko Run Diskobot pro spuštění stejného playbooku se stejnými proměnnými na stejném hostiteli, ale v normálním režimu.

Tlačítko se také používá k restartování playbooku, pokud dojde k jeho zhroucení.

Struktura příruček

Již jsem zmínil, že v závislosti na stavu lístku Jira spouští bot různé playbooky.

Za prvé, je mnohem jednodušší organizovat vstup.
Za druhé, v některých případech je to prostě nutné.

Například při výměně systémového disku musíte nejprve přejít do systému nasazení, vytvořit úlohu a po správném nasazení bude server dostupný přes ssh a můžete na něj nahrát aplikaci. Kdybychom to všechno udělali v jednom playbooku, pak by to Ansible nemohl provést kvůli nedostupnosti hostitele.

Pro každou skupinu serverů používáme role Ansible. Zde se můžete podívat, jak jsou playbooky uspořádány v jednom z nich.

To je pohodlné, protože je hned jasné, kde se které úkoly nacházejí. V main.yml, což je vstup pro roli Ansible, můžeme jednoduše zahrnout na stav tiketu nebo obecné úkoly, které jsou nutné pro každého, například předání identifikace nebo získání tokenu.

vyšetřování.yml

Spuštěno pro vstupenky ve stavech Vyšetřování a Otevřeno. Nejdůležitější věcí pro tuto příručku je název blokového zařízení. Tyto informace nejsou vždy dostupné.

Abychom to získali, analyzujeme souhrn Jira, poslední hodnotu ze spouštěče Zabbix. Může obsahovat název blokového zařízení - štěstí. A může obsahovat bod připojení - pak musíte jít na server, analyzovat a vypočítat požadovaný disk. Spouštěč může také poslat scsi adresu nebo nějaké další informace. Ale také se stává, že neexistují žádné stopy a musíte analyzovat.

Po zjištění názvu blokového zařízení z něj sbíráme informace o typu a velikosti disku pro vyplnění polí v Jira. Odebereme také informace o dodavateli, modelu, firmwaru, ID, SMART a to vše vložíme do komentáře v tiketu Jira. Správce a technik již nemusí tato data hledat. 🙂

připravit2změnit.yml

Pohon mimo rotaci, příprava na výměnu. Nejtěžší, zodpovědná etapa. Zde můžete zastavit aplikaci, pokud ji nelze zastavit. Nebo vytáhněte disk, který postrádal repliky, a tím to mělo vliv na uživatele, ztratíte některá data. Zde máme nejvíce kontrol a upozornění v chatu.

V nejjednodušším případě mluvíme o vyjmutí disku z HW/MD RAID.

Ve složitějších situacích (v našich úložných systémech), kdy se záloha provádí na aplikační úrovni, je potřeba přejít do aplikace přes API, nahlásit vysunutí disku, deaktivovat jej a spustit obnovu.

Nyní masově migrujeme do mraka pokud je server zatažený, pak Diskobot přistoupí k cloudovému API, řekne, že bude pracovat s tímto minionem - serverem, na kterém běží kontejnery - a požádá "migrovat všechny kontejnery z tohoto miniona". A zároveň zapne podsvícení disku, aby inženýr hned viděl, který je potřeba vytáhnout.

změněno.yml

Po výměně disku nejprve zkontrolujeme jeho dostupnost.

Inženýři ne vždy instalují nové disky, takže jsme přidali kontrolu hodnot SMART, se kterými jsme spokojeni.

Na jaké atributy se dívámePočet přerozdělených sektorů (5) < 100
Aktuální počet čekajících sektorů (107) == 0

Pokud disk neprojde testem, je technikovi řečeno, aby jej znovu vyměnil. Pokud je vše v pořádku, podsvícení se vypne, použijí se značky a disk se otočí.

připraven.yml

Nejjednodušší případ: kontrola synchronizace HW / SW raidu nebo ukončení synchronizace dat v aplikaci.

Aplikační API

Několikrát jsem zmínil, že bot často přistupuje k aplikačnímu API. Samozřejmě, že ne všechny aplikace měly potřebné metody, takže musely být dokončeny. Zde jsou nejdůležitější metody, které používáme:

• postavení. Stav clusteru nebo disku, zda je možné s ním pracovat;
• začátek Konec. Aktivace-deaktivace disku;
• Migrovat/obnovit. Migrace a obnova dat během a po výměně.

Vykreslený zážitek od Ansible

Ansible opravdu miluji. Ale často, když se dívám na různé open source projekty a vidím, jak lidé píší playbooky, mám trochu strach. Složité logické prolínání cyklu when /, nedostatek flexibility a idempotence kvůli častému používání shellu / příkazu.

Rozhodli jsme se vše co nejvíce zjednodušit s využitím výhody Ansible – modularity. Na nejvyšší úrovni jsou playbooky, může je napsat každý administrátor, vývojář třetí strany, který o Ansible něco ví.

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

Pokud je nějaká logika obtížně implementovatelná do playbooků, přesuneme ji do modulu Ansible nebo filtru. Skripty lze psát v Pythonu nebo v jakémkoli jiném jazyce.

Píší se snadno a rychle. Například výše uvedený modul pro osvětlení disku má 265 řádků.

Na spodní úrovni je knihovna. Pro tento projekt jsme napsali samostatnou aplikaci, jakousi abstrakci nad hardwarovými a softwarovými RAIDy, které provádějí odpovídající požadavky.

Největší předností Ansible je jeho jednoduchost a snadno srozumitelné playbooky. Myslím, že to musíte použít a negenerovat hrozné yaml soubory a obrovské množství podmínek, shell kódu a smyček.

Pokud si chcete zopakovat naše zkušenosti s Ansible API, mějte na paměti dvě věci:

• Playbook_executor a playbook obecně nelze překročit časový limit. V relaci ssh je časový limit, ale v playbooku žádný časový limit. Pokud se pokusíme odpojit disk, který již v systému neexistuje, playbook poběží neomezeně dlouho, takže jsme jeho spuštění museli zabalit do samostatného obalu a zabít ho časovým limitem.
• Ansible funguje na bázi fork procesů, takže jeho API není bezpečné pro vlákna. Všechny naše příručky spouštíme v jediném vláknu.

Díky tomu jsme byli schopni zautomatizovat výměnu asi 80 % disků. Obecně se náhradový poměr zdvojnásobil. Dnes se administrátor pouze podívá na incident a rozhodne se, zda vyměnit disk nebo ne, a pak udělá jedno kliknutí.

Nyní ale začínáme narážet na další problém: někteří noví správci nevědí, jak změnit disky. 🙂

Zdroj: www.habr.com