Binance Square
#devops

devops

365 skatījumi
19 piedalās diskusijā
I RedOne I
·
--
Vietējās izstrādes neatkarības ilūzija Pāreja no mākoņu infrastruktūras uz pašu uzstādītu lokālo aparatūru nav tikai naudas taupīšana; tā ir strukturāla pārvēršanās uz absolūtu autonomiju. Paļaujoties uz apmaksātiem uzņēmumu serveriem, tiek ieviesta trešo pušu riska un slēptu pretējo pušu saistību problēma. Vietējā arhitektūra, izmantojot neatkarīgus mezglus, garantē absolūtu datu privātumu. #SelfHosted #OpenSource #DevOps #TechAutonomy
Vietējās izstrādes neatkarības ilūzija

Pāreja no mākoņu infrastruktūras uz pašu uzstādītu lokālo aparatūru nav tikai naudas taupīšana; tā ir strukturāla pārvēršanās uz absolūtu autonomiju.
Paļaujoties uz apmaksātiem uzņēmumu serveriem, tiek ieviesta trešo pušu riska un slēptu pretējo pušu saistību problēma. Vietējā arhitektūra, izmantojot neatkarīgus mezglus, garantē absolūtu datu privātumu.

#SelfHosted #OpenSource #DevOps #TechAutonomy
·
--
Kad automatizētā sistēma sāk darboties, kā uzraudzīt, vai tā joprojām ir dzīva Šis ir mans dziļākais mācību brīdis, kad esmu izveidojis vairākas automatizētas plūsmas: **sistēma nevar nomirt naktī un likt tev to atklāt tikai nākamajā dienā**. Es reiz esmu izvietojis plānotu uzdevumu, domājot, ka, iestatot cron, varu to atstāt bez uzraudzības. Rezultātā, kad pēc nedēļas devos pārbaudīt statusu, es atklāju, ka tā jau 3 dienas ir klusējusi - datubāzes savienojums bija pārtraukts, un nebija nekādu paziņojumu. Kopš tā laika esmu izveidojis pilnīgu uzraudzības filozofiju, ko šodien dalīšos ar jums. **Pirmais līmenis: izpildes cikla uzraudzība** Pamatmetode ir apskatīt cron pēdējo izpildi last_run_at. Mana noteikums ir: **ja pēdējā izpildes laiks pārsniedz paredzēto ciklu 2 reizes, nekavējoties aktivizēt brīdinājumu**. Piemēram, ja uzdevumam vajadzētu darboties ik pēc 5 minūtēm, ja last_run_at ir vairāk nekā 10 minūtes no tagadnes, tad uzreiz sūtu brīdinājumu uz Telegram. Šis rādītājs ir ārkārtīgi efektīvs - apmēram 90% no "sistēma ir avarējusi" var tikt atklāti 1 stundas laikā, nevis pasīvi gaidot, kad biznesa nodaļa to pamanīs. **Otrais līmenis: API pārtraukšanas mehānisms** API nestabilitāte ir norma. Mana pieeja ir: **ja 3 reizes pēc kārtas API pieprasījums neizdodas, automātiski pārtraukt uz 24 stundām**. Kāpēc 3 reizes? Jo 1-2 reizes var būt tīkla svārstības, bet 3 reizes pēc kārtas neizdošanās norāda uz reālu problēmu. Pārtraukšanas laikā sistēma vairs nemēģina veikt pieprasījumus, lai izvairītos no dārgu API resursu un žurnālu vietas izšķērdēšanas nepareizā stāvoklī. Tas ir daudz efektīvāk nekā akli atkārtot pieprasījumus. **Trešais līmenis: statusa faila noturība** Katru reizi, kad sistēma darbojas, es ierakstu pašreizējo stāvokli - veiksmīgu pieprasījumu skaitu, neveiksmīgu skaitu, laika zīmogu, kļūdu informāciju - statusa failā. Šo failu es glabāju 30 dienas. Kāda ir šī pieejas priekšrocība? Varu atgriezties atpakaļ - "kāpēc pagājušajā trešdienā ziņojumu izsūtīšanas līmenis pēkšņi nokritās līdz 60%?" - vienkārši pārlūkojot žurnālus ir atbilde. Statusa fails neaizņem vietu, bet sniedz man pilnīgu revīzijas ķēdi. **Ceturtais līmenis: nedēļas cilvēka pārskats** Katrā nedēļā, veltot 15 minūtes, es ļauju sistēmai automātiski ģenerēt kopsavilkuma ziņojumu: ziņojumu izsūtīšanas veiksmes līmenis, kļūdu līmeņa sadalījums, vārdu skaits, vai ir bijušas anomālijas. Nav nepieciešams ļoti bieži, bet **nav jāpaļaujas tikai uz automātiskajiem brīdinājumiem**. Dažreiz tendences, kad kļūdu līmenis no 2% pieaug līdz 4%, automātiskā uzraudzība to neziņos, bet cilvēks to uzreiz pamanīs un sapratīs, ka "šeit jāpievērš uzmanība". **Galvenā atziņa** Automatizācija tiek uzbūvēta ātri, bet **ja uzraudzība ir pareiza, tad varu būt drošs, neuzņemoties pastāvīgu uzraudzību**. Mana pieredze ir: automātiskie brīdinājumi atbild par ārkārtas situācijām (sistēma pilnībā avarējusi), bet cilvēka pārskats atbild par tendences jautājumiem (pakāpeniska pasliktināšanās). Abas pieejas kopā dod šai sistēmai ilgu dzīvi. Citādi pat visgudrākā automatizācija ir tikai laika sprādziens melnā kastē. $BTC #DevOps #automātizācija
Kad automatizētā sistēma sāk darboties, kā uzraudzīt, vai tā joprojām ir dzīva

Šis ir mans dziļākais mācību brīdis, kad esmu izveidojis vairākas automatizētas plūsmas: **sistēma nevar nomirt naktī un likt tev to atklāt tikai nākamajā dienā**.

Es reiz esmu izvietojis plānotu uzdevumu, domājot, ka, iestatot cron, varu to atstāt bez uzraudzības. Rezultātā, kad pēc nedēļas devos pārbaudīt statusu, es atklāju, ka tā jau 3 dienas ir klusējusi - datubāzes savienojums bija pārtraukts, un nebija nekādu paziņojumu. Kopš tā laika esmu izveidojis pilnīgu uzraudzības filozofiju, ko šodien dalīšos ar jums.

**Pirmais līmenis: izpildes cikla uzraudzība**

Pamatmetode ir apskatīt cron pēdējo izpildi last_run_at. Mana noteikums ir: **ja pēdējā izpildes laiks pārsniedz paredzēto ciklu 2 reizes, nekavējoties aktivizēt brīdinājumu**. Piemēram, ja uzdevumam vajadzētu darboties ik pēc 5 minūtēm, ja last_run_at ir vairāk nekā 10 minūtes no tagadnes, tad uzreiz sūtu brīdinājumu uz Telegram. Šis rādītājs ir ārkārtīgi efektīvs - apmēram 90% no "sistēma ir avarējusi" var tikt atklāti 1 stundas laikā, nevis pasīvi gaidot, kad biznesa nodaļa to pamanīs.

**Otrais līmenis: API pārtraukšanas mehānisms**

API nestabilitāte ir norma. Mana pieeja ir: **ja 3 reizes pēc kārtas API pieprasījums neizdodas, automātiski pārtraukt uz 24 stundām**. Kāpēc 3 reizes? Jo 1-2 reizes var būt tīkla svārstības, bet 3 reizes pēc kārtas neizdošanās norāda uz reālu problēmu. Pārtraukšanas laikā sistēma vairs nemēģina veikt pieprasījumus, lai izvairītos no dārgu API resursu un žurnālu vietas izšķērdēšanas nepareizā stāvoklī. Tas ir daudz efektīvāk nekā akli atkārtot pieprasījumus.

**Trešais līmenis: statusa faila noturība**

Katru reizi, kad sistēma darbojas, es ierakstu pašreizējo stāvokli - veiksmīgu pieprasījumu skaitu, neveiksmīgu skaitu, laika zīmogu, kļūdu informāciju - statusa failā. Šo failu es glabāju 30 dienas. Kāda ir šī pieejas priekšrocība? Varu atgriezties atpakaļ - "kāpēc pagājušajā trešdienā ziņojumu izsūtīšanas līmenis pēkšņi nokritās līdz 60%?" - vienkārši pārlūkojot žurnālus ir atbilde. Statusa fails neaizņem vietu, bet sniedz man pilnīgu revīzijas ķēdi.

**Ceturtais līmenis: nedēļas cilvēka pārskats**

Katrā nedēļā, veltot 15 minūtes, es ļauju sistēmai automātiski ģenerēt kopsavilkuma ziņojumu: ziņojumu izsūtīšanas veiksmes līmenis, kļūdu līmeņa sadalījums, vārdu skaits, vai ir bijušas anomālijas. Nav nepieciešams ļoti bieži, bet **nav jāpaļaujas tikai uz automātiskajiem brīdinājumiem**. Dažreiz tendences, kad kļūdu līmenis no 2% pieaug līdz 4%, automātiskā uzraudzība to neziņos, bet cilvēks to uzreiz pamanīs un sapratīs, ka "šeit jāpievērš uzmanība".

**Galvenā atziņa**

Automatizācija tiek uzbūvēta ātri, bet **ja uzraudzība ir pareiza, tad varu būt drošs, neuzņemoties pastāvīgu uzraudzību**. Mana pieredze ir: automātiskie brīdinājumi atbild par ārkārtas situācijām (sistēma pilnībā avarējusi), bet cilvēka pārskats atbild par tendences jautājumiem (pakāpeniska pasliktināšanās). Abas pieejas kopā dod šai sistēmai ilgu dzīvi. Citādi pat visgudrākā automatizācija ir tikai laika sprādziens melnā kastē.

$BTC #DevOps #automātizācija
Drošības brīdinājums: CZ tikko ielika katru $BNB ķēdes izstrādātāju trauksmes režīmā GitHub repozitoriji ir apdraudēti. Piekļuves akreditīvi ir noplūduši. Izstrādes cauruļvadi visā atvērtā koda kriptovalūtu projektos ir pakļauti mērķtiecīgiem uzbrukumiem. CZ ziņojums visiem būvētājiem: jūsu GitHub atslēgas ir tikpat svarīgas kā jūsu biržas maki. Viens vājš posms jūsu izstrādes cauruļvadā nozīmē uzbrucējus jūsu protokolā. BNB ķēde hostē simtiem atvērtā koda DeFi projektu. Publiski forkots kods rada plašāko uzbrukuma virsmu kriptovalūtās. Ar miljardiem uz spēles, vājākais posms ir jūsu operāciju drošība. Steidzami: Audīt repozitorijus. Mainīt atslēgas. Pieņemiet, ka nekas nav drošs. $BNB #BNBChain #CryptoSecurity #DevOps #OpSec
Drošības brīdinājums: CZ tikko ielika katru $BNB ķēdes izstrādātāju trauksmes režīmā

GitHub repozitoriji ir apdraudēti. Piekļuves akreditīvi ir noplūduši. Izstrādes cauruļvadi visā atvērtā koda kriptovalūtu projektos ir pakļauti mērķtiecīgiem uzbrukumiem.

CZ ziņojums visiem būvētājiem: jūsu GitHub atslēgas ir tikpat svarīgas kā jūsu biržas maki. Viens vājš posms jūsu izstrādes cauruļvadā nozīmē uzbrucējus jūsu protokolā.

BNB ķēde hostē simtiem atvērtā koda DeFi projektu. Publiski forkots kods rada plašāko uzbrukuma virsmu kriptovalūtās. Ar miljardiem uz spēles, vājākais posms ir jūsu operāciju drošība.

Steidzami: Audīt repozitorijus. Mainīt atslēgas. Pieņemiet, ka nekas nav drošs.

$BNB #BNBChain #CryptoSecurity #DevOps #OpSec
·
--
Pozitīvs
GitHub iekšējais pārkāpuma brīdinājums 🚨: TeamPCP apgalvo, ka ~4,000 privātu repozitoriju ir izsūknēti, izmantojot ļaunprātīgu VS Code paplašinājumu darbinieka ierīcē. • Klientu dati nav noplūduši (vēl). • Piegādes ķēdes uzbrukumi ir jaunā norma. • Rīcība: Audita jūsu paplašinājumus, mainiet slepenos datus un nostipriniet galapunktu drošību. Nebūt vājākais posms. 🛡️ #GitHub #CyberSecurity #TeamPCP #DevOps #SecurityAlert
GitHub iekšējais pārkāpuma brīdinājums 🚨: TeamPCP apgalvo, ka ~4,000 privātu repozitoriju ir izsūknēti, izmantojot ļaunprātīgu VS Code paplašinājumu darbinieka ierīcē.
• Klientu dati nav noplūduši (vēl).
• Piegādes ķēdes uzbrukumi ir jaunā norma.
• Rīcība: Audita jūsu paplašinājumus, mainiet slepenos datus un nostipriniet galapunktu drošību.
Nebūt vājākais posms. 🛡️
#GitHub #CyberSecurity #TeamPCP #DevOps #SecurityAlert
Piesakies, lai skatītu vairāk satura
Pievienojies kriptovalūtu entuziastiem no visas pasaules platformā Binance Square
⚡️ Lasi jaunāko un noderīgāko informāciju par kriptovalūtām.
💬 Uzticas pasaulē lielākā kriptovalūtu birža.
👍 Atklāj vērtīgas atziņas no pārbaudītiem satura veidotājiem.
E-pasta adrese / tālruņa numurs