Rörelsen DevOps

[ARKIVERAD] Senast uppdaterad av Joe Schaefer den Fri, 26 Apr 2024    källa
 

Mer än att bara ge utvecklare rotåtkomst!

Eller inte ens det. Den stora idén bakom “rörelsen” är inte bara att ge utvecklare mer rep

Begränsningshantering är nyckeln till processen. Genom att först identifiera alla flaskhalsar i systemet kan du fokusera dina ansträngningar på att optimera dessa resurser för att uppnå maximal effekt. Optimeringar bortom dessa områden är nästan alltid inte värt besväret —

Trunkbaserad utveckling

Uppmuntra till inkrementella ändringar med automatiserade testnings-, marknadsförings- och frisläppningsprocesser i en schemalagd takt är ett bra sätt att få bollen i rullning, men en stor del av kvalitetskontrollen i SaaS/PaaS-distributioner innebär att du inför *stambaserad utveckling.

I huvudsak multiversum av långsiktiga stjärt

        Surgery on a patient must result
        in good outcomes (at all times) for
        that patient, not just for siblings
        or future generations.

CI-/CD-pipeliner

Trunk Based Development är grunden för alla därmed automatiserade förändringskontrollledningar som har vuxit upp under de senaste två decennierna.

Kod är lag (Utveckling + Infrastruktur + Konfiguration).

Lite historiskt perspektiv först; slaglinjen följer dessa fyra stycken. Den gemensamma tråden här är att Apache nästan alltid har varit före sin tid.

Tillbaka i pre-CFEngine.

Arbetsflödet var mindre än perfekt: förutom att bygga våra egna lokalt lappade FreeBSD-portar i driftsättningsbara (binära) paket från grunden var personalen tvungen att utöva svår att upprätthålla disciplin när de distribuerade ändringar i produktionen, genom att först bekräfta versionskontroll, logga in på målservern, uppdatera kassan och eventuellt starta om tjänsten —

Numera håller de allt i en stjärt-backed marionett källträd, och provision / driftsätta / konfigurera direkt till molnet med hjälp av generiska uppströms Ubuntu-paket, vilket är en något modern inställning till deras IT-ops arbete, eftersom planerat stjärt

Å andra sidan var ett tidigt, banbrytande CI-liknande initiativ vid ASF (för faktiska Apache-programvara TLP-projekt) Apache Gump.

Här är punkten i ett nötskal: alla dina källor (utveckling, infrastruktur och konfiguration) tillhör versionskontroll (inte nödvändigtvis samma datalager) som kan granskas av all utvecklingspersonal och är en del av din fullständiga uppsättning testautomatiseringspipeliner mellan korrigeringsversioner och produktionsdistributioner. En undersökning av den senaste tekniken, där förändringar testas/tilldelas/distribueras på begäran i IaC/CaC inställningar, finns på min vän och visionär Paul Hammants hemsida här.

Virtualisering kontra containerisering: en Husdjur vs. boskap.

Containersystem som Docker är anpassningsbara, omdistribuerbara virtualiseringstekniker som vanligtvis används för att stödja ett MicroService Architecture (MSA) -ramverk för applikationskluster som Kubernetes. De plockar upp där virtualiseringssystem slutade, handel obegränsat stöd av (helt) isolerade per-VM operativsystem för Linux-kernel baserade virtuella maskiner som har betydligt mer programmerbar anpassning och integration med den överordnade Linux värd som de körs på. Dessutom kan de byggas om och uppladdas till en central distributionstjänst (som artefakt) för storskalig återanvändning över flera beroendekedjor och råa körbara serverdistributioner.

Vertikal kontra horisontell skalning

Omkonfigurerbara containrar som kan laddas ned från en central server gör det möjligt att utnyttja de möjligheter som är svåra att förverkliga med grundläggande virtualiseringsteknik - du är inte låst till någon enskild servers hårdvarugränser för att skala ut dina tjänster för att möta efterfrågan. Med andra ord är horisontell skalning genom att distribuera samma behållare över samlingar av värdar, ** på begäran**, en omedelbart uppnåelig förstklassig funktion i MSA-ramverk baserade på Docker. Precis som när du distribuerar dussintals fler containrar än processorkärnor på värden samma.

Mät, bromsa och kontrollera brandbekämpningsinsatser, både verkliga och praktiska

En av de andra viktiga sakerna att känna igen är att skilja mellan planerat och * oplanerat* arbete i någon av dina produktivitetsmätvärden och hur resurser allokeras till dessa uppgifter. Oplanerat arbete uppgår till firefighting, och om för mycket tid (mer än ~20 %) spenderas på dessa uppgifter, blir det planerade arbetet, vilket är det verkliga affärsbehovet för företaget, eftersläpande.

Flaskhalsarna i systemet klarar sällan av oplanerat arbete, så det är viktigt att ha tillräckligt med extra resurser för att hantera den ökade belastningen och efterföljande eftersläpning.

En av de viktigaste lärdomarna av COVID-19 i början av 2020, som sjukhuskapacitet när det gäller IT, är att det finns en sådan sak som att vara för lean, åtminstone när det gäller devops bemanning (hårdvara är en annan historia). Beredskapsplanering för en regnig dag, antingen med “redundant” personal eller cross-training initiativ, kombinerat med regelbundna förberedande övningar, håller inte bara doktorn borta, men är faktiskt ** uppdragskritisk**.

Komma med programmet

På ledningsnivå är ett globalt förändringshanteringsperspektiv mellan både devs och ops förändringar avgörande. Båda grupperna måste vara medvetna om varandras förändringar. Helst med planeringsdetaljer som görs tillgängliga längs vägen. Stora saker kan hända när lagen är en hälsosam blandning av utvecklare och ops-personal, i en datastyrd, transparent kultur av samarbetsarbete.

Filosofin om att inkludera många intressenter i skapandet, och evolution, av en konkret arbetsprodukt har konsekvenser långt bortom bara * dev * och *ops * team som delar kontroll och ansvar för en serverteknikinsats. Denna lektion fortsätter att upprepas i hela den moderna företagsvärlden, eftersom nya domäner för kreativt mänskligt uttryck tar form i näringslivet, liksom att återuppfinna gamla sätt att göra affärer tillsammans.

Permalänk  #utvecklare  

 

 

Kommentarer  


Bilagor  

Länkar  


Index

- [Tredubbla produkter av egenfunktioner och spektral geometri](/joe/triple-products.html.sv) &mdash; Vi avslöjar en roman, men bekant, global geometrisk invariant ... <small><em>Sun, 28 Apr 2024</em></small>

Hyperbolisk honungskaka

- [Stokastisk spårningsformel för stängda, negativt böjda grenrör](/joe/stochastic-trace-formula.html.sv) &mdash; Min * 1997 Ph.D. avhandling* som ett blogginlägg. ... <small><em>Fri, 26 Apr 2024</em></small>

tjärad och fjädrad

- [Apache HTTPd Devs ansåg vara skadliga](/joe/apache-considered-harmful.html.sv) &mdash; Philip visste inte mycket då var hur fullständigt [peevish, vapid och territorial](https://www.mail-archive.com/dev@httpd.apache.org/msg77781.html) Det laget hade blivit ... <small><em>Fri, 26 Apr 2024</em></small>

Beroenden för engelska

- [Vad handlar <em>Smart Content Dependency ManagementTM</em> om?](/joe/dependencies.html.sv) &mdash; En tydlig förståelse av din webbplats *beroende graf* kommer att se till att du kan maximera prestandan hos vår byggteknik i stor skala ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Roligt med htop](/joe/fun-with-htop.html.sv) &mdash; Avancerade funktioner på populära Unix-plattformar ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Git och non repudement](/joe/git-and-non-repudiation.html.sv) &mdash; Det finns en tydlig skillnad mellan "åtagandets" historia och "uppladdningens" historia. ... <small><em>

Denna uppsats gäller verkligen DVCS i allmänhet, inte bara git per se. Men vi kommer att fokusera uppmärksamheten på git eftersom det fortfarande är den mest populära DVCS runt idag.

Ej avvisande.

Med ett traditionellt centraliserat versionskontrollverktyg är sådana poster lätt tillgängliga från bekräftelsehistoriken. Varje bekräftelse till systemet går igenom en auktoriseringsmekanism för att säkerställa att den person som gjorde ändringen har behörighet att ladda upp den. Dessa register är avgörande för företaget för att säkerställa att korrekta register förs som visar vem som är ansvarig för att ladda upp varje kodrad till programvaran i fråga.

Med git, eller distribuerad versionskontroll i allmänhet, {# lede #}Det finns en tydlig skillnad mellan "åtagandets" historia och "uppladdningens" historia.{# lede #} &mdash; som jag kommer att hänvisa till som "push records". Bekräftelser i git autentiseras inte, eftersom de sker lokalt, med lokala, overifierade metadata tillagda i historiken. Uppladdningssteget, aka git push

Med Apache Software Foundation.

Varför är detta viktigt? Tja till att börja med låt mig ta itu med en vanlig missuppfattning om behovet av bidragsgivare licensavtal (ICLA) för Apache-företag. Många verkar inte förstå att det inte finns någon skillnad mellan det tillämpliga språket i de enskilda författarverken. ICLA och Apache-licens 2.0.

Vad push-poster ger då är ett sätt att spåra tillbaka, till varje rad av kod i en release, den enskilda committer som ansvarar för att driva den koden till ASF: s git-datalager. Detta är kritiskt viktigt för att bestämma härkomst av ett bidrag från tredje part med git, eftersom det tyvärr är möjligt för en sådan bidragsgivare att "gå bort" från sitt bidrag till ett git-projekt på grund av den distribuerade typen av DVCS-loggar. Den ansvariga parten blir då, enligt ICLA, den beställare som drev koden.

Tidiga och korrekta begränsningsstrategier kretsar kring att ta bort det övergivna bidraget, men skadorna på projektet kan redan ha gjorts. Och utan push-rekorden skulle vi bokstavligen inte ha någon auktoritativ process för att bestämma hur den koden faktiskt kom in i vårt lager, annat än att tråla igenom alternativa poster i problemspårare eller on-list-kommunikation. Att enbart förlita sig på sammanslagningsbekräftelseloggar för att bestämma härkomst är inte särskilt tillfredsställande ur säkerhetssynpunkt, eftersom det kräver strikt efterlevnad av en viss typ av arbetsflöde, som vi inte vill diktera.

Utan sådana saker skulle vi behöva mandat åtminstone PGP-signering av varje bidragsgivares åtagande, vilket är betungande för många projekt. Push-poster ger en transparent process som inte påverkar ett projekts arbetsflöde, annat än för att säkerställa att ASF:s git-datalager är det verkliga huvuddatalagret.

$Datum: 2023-01-19 22:58:40 +0000 (Thu, 19 Jan 2023) $


Informationsarkitektur

- [Informationsarkitektur](/joe/ia.html.sv) &mdash; Hela skalan av teknik som är relevant för design, presentation, relationer och arkitektoniska begränsningar som täcker varje URL du tjänar ... <small><em>Fri, 26 Apr 2024</em></small>

Drakens år

- [Joe's slumpmässiga tankar](/joe/index.html.sv) &mdash; Välkommen! ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Informationssäkerhet - introduktion](/joe/infosec.html.sv) &mdash; Alla data som kommer från ett exekverings-UNIX **systemanrop** ska behandlas som **behållna** ... <small><em>

Vad är det primära målet för InfoSec?

För att säkerställa att alla förändringar vid kontextgränser är väl reglerade.

Till exempel uppfyller varje systemanrop på en UNIX-plattform detta villkor när det gäller UNIX-säkerhetsmodell för användare/gruppprocess+filesystem. Den litterala definitionen av en kontextväxel, vilket anges av systemanrop, inbegriper en kontroll av API-användningssäkerheten på kärnans sida av anropet.

När det gäller leverans av SaaS, {# lede #}alla data som kommer från ett exekverings-UNIX systemanrop ska behandlas som behållna{# lede #}

UNIX säkerhetsmodell ensam gjorde aldrig bestämmelser för nätverksansluten klient / server applikationsutveckling, eftersom historiskt BSD socket API som föregick ökningen av Network Computing på 90-talet (Sun Microsystems) uppfanns över ett decennium efter UNIX föddes (med sin OS-baserade multiuser säkerhetsmodell helt bildad vid födseln). MIT Kerberos.

Schemalägga CPU:er på ett säkert sätt för att utföra arbete på kärnnivå för någon "auktoriserad användar-/grupp-/rollkontext" som inte är kopplad till den underliggande processens UNIX-användar-/gruppkontext har alltid legat utanför UNIX-modellen. Många infosec initiativ misslyckas med att erkänna detta regulatoriska ansvar tillhör program ensam; Låt inte din vara en!

Om det inte är klart vid denna tidpunkt, bör DevOps/SRE-team triaging SaaS security (CAI) incidenter på Linux bekanta sig med htops stjärt gränssnitt via ss nyckel! Bättre att behärska stjärt

Hur relaterar detta till Zero-Trust-initiativ, som en praktisk fråga?

Nolltillförlitlig arkitektur.

Även om det kan finnas VPN/Firewall-kontexter i verkligheten är ingen av dessa detaljer relevanta för InfoSec inom ett Zero-Trust-ramverk. Med andra ord kan sådana nätverkstopologisäkerhetsinitiativ öka Zero-Trust-initiativ, men de förlitar sig aldrig på inom ett Zero-Trust-initiativ på basserverns värdsäkerhetsnivå upp genom applikationsnivån.

MIT Kerberos och Active Directory är till exempel kompatibla med Zero-Trust.

$Datum: 2023-01-19 22:58:40 +0000 (Thu, 19 Jan 2023) $


 

- [Utskickslistor](/joe/mailing-lists.html.sv) &mdash; Dessa tillfälliga adresser är anathema för `ezmlm-idx`'s abonnemang och modereringssystem ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Applikationsprestanda](/joe/performance.html.sv) &mdash; Många utvecklare faller i fällan att tänka prestandaoptimering handlar om att göra varje rad av kod så effektiv som möjligt. ... <small><em>Fri, 26 Apr 2024</em></small>

- [Perl 7 Funktionsbegäran: förseglade underdelar för typangivna lexikaler](/joe/perl7-sealed-lexicals.html.sv) &mdash; Perl 5:s OO-exekveringsmetoduppslagning har 50 % mer prestandakostnader än ett direkt, namngivet subrutinanrop ... <small><em>Fri, 26 Apr 2024</em></small>

COVID-19 i mars 2020

- [Exponentiell tillväxt och COVID-19](/joe/power.html.sv) &mdash; Ta din tid med ** matte** avsnittet &mdash; Det är viktigt att vara en utbildad konsument av statistik som är relevant för den nuvarande pandemin ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Om skräppostproblemet...](/joe/spam.html.sv) &mdash; Bästa plugin för `qpsmtpd`Även om det är svårt att förstå varför ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Informationssäkerhet, applikationsprestanda och tillförlitlighet](/joe/spr.html.sv) &mdash; "Icke-funktionell" programvaruteknik handlar om tre huvudfrågor: säkerhet, prestanda och tillförlitlighet (**SPR**) ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Glädjen i DTrace](/joe/joy-of-dtrace.html.sv) &mdash; Mät två gånger, skära en gång innan du påbörjar ett arbete med kodoptimering ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Glädjen i htop](/joe/joy-of-htop.html.sv) &mdash; Hotell nära Solaris 11 ... <small><em>Thu, 25 Apr 2024</em></small>