Kriittisten järjestelmien alasajon korkeat kustannukset

Esimerkiksi New Yorkin pörssin 2015 katkokset maksavat miljoonia menetetyissä kaupoissa, kun taas sairaalan infuusiopumpussa oleva ohjelmistovirhe voi vaarantaa potilaan elämän. Jopa lyhyen seisokin kriittisessä konepajajärjestelmässä voi johtaa turvallisuusvaaroihin, sääntelyyn liittyviin seuraamuksiin ja mainevaurioihin. Uudelleenjärjestelykoodin korjaaminen ilman, että sen ulkoista käyttäytymistä muutetaan, on kurinalainen lähestymistapa, jolla vähennetään teknistä velkaa ja parannetaan järjestelmän sietokykyä, mutta se on toteutettava tarkasti, jotta vältetään uusien riskien käyttöönotto.

Keskeiset refaktorointiperiaatteet alasajoajan minimoimiseksi

Tehokas refaktorointi tehtäväkriittisissä ympäristöissä perustuu kolmeen pilariin: [] käyttäytymisen säilyttäminen[], []incremental change[], ja []-puolustustestaus[[]]. Käyttäytymisen säilyttäminen varmistaa, että jokainen refaktorointivaihe jättää järjestelmän havaittavissa olevat tuotokset identtisiksi. Lisääntymismuutos rajoittaa yksittäisen muutoksen räjähdyssädettä. Puolustustesti varmistaa, ettei regressiota ole tapahtunut jokaisessa vaiheessa. Näiden periaatteiden noudattaminen vähentää alasajoajan todennäköisyyttä aikana ja sen jälkeen.

Turvallisen korjaamisen avainstrategiat

Rinnakkaisjuoksut ja varjotila

Varjotilassa refaktoroitu komponentti kulkee alkuperäisen järjestelmän rinnalla, prosessoi samoja syötteitä mutta hylkää hiljaa sen lähdöt. Insinöörit vertaavat tuloksia havaitakseen eroja vaikuttamatta live-toimintoihin. Kun luottamus on korkea, varjokomponentti voidaan edistää ensisijaiseksi tilaksi. Tämä tekniikka on erityisen hyödyllinen ydinalgoritmeille tai tietojenkäsittelyputkille, joissa oikeellisuus on tärkeintä.

Ominaisuusvaihtoehdot

Ominaisuudet kytkimet (tai liput) avulla voit kääriä refaktoroitu koodi takana asetuskytkin. Refaktoroitu polku pysyy ei-aktiivisena, kunnes nimenomaisesti päälle, antaa joukkueet kyky ottaa se asteittain tai siirtää takaisin heti, jos ongelmia ilmenee. Kriittisissä järjestelmissä, kytkimet pitäisi olla staattinen (asettaa käyttöönottohetkellä) eikä dynaaminen välttää odottamaton käyttäytyminen runtime muutoksia.

Kanariansaarten päästötiedot

Kanariansaarten julkaisu ohjaa pienen osan liikenteestä regeneroituun järjestelmään, kun suurin osa jatkaa vakaata versiota. Tämä lähestymistapa tarjoaa reaaliaikaisen validoinnin tuotantokuormalla. Jos kanarialinnun virhetaso on korkea tai viive, liikenne voidaan ohjata välittömästi uudelleen. Fyysisiä laitteita ohjaavien teknisten ohjelmistojen osalta kanariansaarten julkaisut saattavat vaatia erityisiä testiympäristöjä, jotka peilaavat tuotantoa mutta jotka ovat erillään elävistä toiminnoista.

Sininen vihreä käyttöönotto

Sininen-vihreä käyttöönotto ylläpitää kahta samanlaista ympäristöä: ...Blue... ja vihreä.Vihreän ympäristön perusteellisen validoinnin jälkeen liikenne siirtyy sinisestä vihreään yhdessä atomioperaatiossa. Jos ongelmia ilmenee, siniseen siirtyminen tapahtuu yhtä nopeasti. Tämä strategia on tehokas kansalaisuudettomien sovellusten kannalta ja sitä voidaan mukauttaa tilallisiin järjestelmiin, joissa on huolellinen tietojen synkronointi.

Suunniteltu huolto-ikkuna

Parhaista ponnisteluista huolimatta joitakin korjauksia ei voida ottaa käyttöön avoimesti. Tällaisissa tapauksissa aikataulumuutokset määriteltyjen huolto-ikkunoiden aikana . Mieluiten silloin, kun järjestelmän kuormitus on pienin. Ilmoita ikkunasta selvästi sidosryhmille ja varmista, että uudelleenkäynnistysmenettelyt harjoitellaan ja dokumentoidaan. Älä koskaan käytä korjauskertoimia huipputoiminta-aikoina tai välittömästi ennen kriittisiä määräaikoja.

Rakentaminen kestävä testaus putki

Yksikkö- ja integrointitestit

Kokonaisvaltainen testisarja ei ole neuvoteltavissa kriittisille järjestelmille. Yksikkötestit vahvistavat yksittäisten toimintojen oikeellisuuden, kun taas integrointitestit vahvistavat, että uudelleen muokatut moduulit ovat vuorovaikutuksessa olemassa olevien komponenttien kanssa. Käytä []testipeitetyökaluja[[]] testaamatta jäävien koodipolkujen tunnistamiseksi. Turvallisuuden kannalta kriittisten ohjelmistojen osalta harkitse [-formaalia todentamista[]] tai [[]-mallipohjaista testausta[[]] osoittaa matemaattisesti, että käyttäytyminen pysyy muuttumattomana. [[]Refaktorointi[[[] Martin Fowlerin sivustolla on klassisia esimerkkejä käyttäytymisen kannalta kestävistä muunnoksista, jotka on tuettava testeillä.

Regressiotestaus ja jatkuva integrointi

Automatisoitu regressiotesti suoritetaan jokaiselle toimitussaalisvirheelle aikaisin. Jatkuva integrointi (CI) putkistot pitäisi suorittaa koko regressiosarja minuutissa. Kriittisten järjestelmien osalta suoritetaan myös []suoritus regressiotestit[] sen varmistamiseksi, että korjaus ei heikennä ajoitusta tai resurssien käyttöä. [ Regressiotestisarja[[] huolto on välttämätöntä, kun korjaat vian, lisää testi, joka toistaa sen ennen korjausta.

Kaaostekniikka kestävyysvalidointia varten

Kaaostekniikka tarkoituksellisesti ruiskuttaa järjestelmän toimintahäiriöitä tarkkailla, miten se käyttäytyy stressin alla. Sovellettu korjattuja komponentteja, se voi paljastaa oletuksia, jotka ovat muuttuneet tai uusia vikatiloja käyttöön rakenneuudistus. Työkalut kuten []Chaos Engineering[] voi simuloida verkkoosiot, resurssien ehtyminen, tai äkillisiä murtoja liikenteen. Tämä kurinalaisuus on hyväksynyt organisaatiot kuten Netflix ja Amazon varmistaa selviytymiskyvyn järjestelmiä, joilla ei ole varaa seisokki.

Kriittisten järjestelmien korjaustoimenpiteiden toteutusvaiheet

Arviointi ja suunnittelu

Aloita järjestelmän arkkitehtuurin perusteellisella analyysillä. Tunnista moduulit, jotka ovat tarkkaan määriteltyjä, joilla on korkea testikattavuus ja jotka on eristetty turvallisuuskriittisistä poluista. Käytä [riippuvuuskaavioita[] ymmärtääksesi vaikutuksia. Rank refaktoroi ehdokkaita riskin ja liikearvon mukaan. Käynnistä verkkotunnuksen asiantuntijat.

Version ohjaus ja peruutus

Jokainen refaktorimuutos on sitouduttava erilliseen haaraan selkeällä toimitusviestillä, jossa kuvataan muutos. Tag the stabiled release ennen työn aloittamista. Rockback-suunnitelman tulisi sisältää koodin palautumisen lisäksi myös mahdolliset tietokantojen siirtymät tai konfiguraatiomuutokset, jotka on peruttava. Harjoittele uudelleenvetoa vaiheympäristössä, jotta siitä tulee toinen luonto tapahtuman aikana.

Tilanmääritysympäristö

Laaditaan järjestelmä, joka peilaa laitteiston tuotantoa, verkkotopologiaa ja datan määrää, jotta voidaan varmistaa turvallinen korjaus. Suorita testisarja ja suorituskyvyn vertailuarvot tässä. Ohjelmistoille, jotka liittyvät fyysisiin koneisiin (esim. robottiohjaimet, sähköverkkomonitorit), porrastuksen tulisi sisältää simulointisilmukat, jotka toistavat reaalimaailman syötteitä ja lähtöjä. Vasta kun vaihe läpäisee kaikki kriteerit, pitäisi siirtyä tuotantoon.

Seuranta ja tarkkailu

Jälkikäteen tehdyn seurannan on seurattava sekä toiminnallista oikeellisuutta että toiminnallista terveyttä. Asennettava [ hälytys[ virhetasopiikkien, latenssin lisääntymisen ja resurssien kulutuksen muutosten varalta. Käytä hajautettua jäljitystä pyyntöjen seuraamiseksi korjattujen koodipolkujen kautta. Kriittisissä järjestelmissä ei valvota ainoastaan ohjelmistoa vaan myös mahdollisia siihen liitettyjä laitteistoja poikkeavuuksia varten. Säilytä kojelauta, joka vertaa esi- ja jälkikorjausmittareita vähintään yhteen normaalin toiminnan sykliin.

Kriittisten koodien yhteiset korjaustekniikat

Kaikki korjaustekniikat eivät ole yhtä turvallisia.

  • Otemenetelmä[ ... .........................................................................................................................................................................................................................................
  • Nimeä muuttuja tai toiminto[ . ... ....................................................................................................................................................................................................................................
  • Korjaa Magic-numero symbolisella vakio[ . ... ... .. .. .. .. .. .. .. ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  • Yksinkertaistetaan ehdollisia ilmauksia[ . ... ...................................................................................................................................................................................................................................
  • Edusta Parametriobject ... ...................................................................................................................................................................................................................................

Jokainen tekniikka on käytettävä erillään, testattuna ja ennen seuraavaa. Ohjelmiston parannusryhmän valkoinen kirja turvallisuuden kannalta kriittisten järjestelmien korjaamisesta[ tarjoaa käytännön ohjeita oikean lähestymistavan valitsemisesta korkean luotettavuusympäristön tarpeisiin.

Riskien lieventäminen ja hallinta

Koodin tarkastelu ja parin ohjelmointi

Jokaisen refaktorointisitoumuksen on oltava vähintään kahden järjestelmän tutun insinöörin tarkistama. Pariohjelmointi refaktorointisession aikana voi estää triviaaleja virheitä ja edistää tiedon siirtoa. Arvosteluissa on keskityttävä käyttäytymisen säilyttämiseen, testikattavuuteen ja refaktorointisuunnitelman noudattamiseen.

Asiantuntijavalidointi

Kriittisillä aloilla on mukana subjekti-materia-asiantuntijoita (pk-yrityksiä), jotka ymmärtävät ohjelmiston koodauksen fysiikan, kemian tai operatiivisen logiikan. Pk-yritys saattaa huomata, että uudelleen nimetty muuttuja on nyt ristiriidassa laajalti käytetyn alan lyhenteen kanssa tai että uutetaan menetelmä, joka vahingossa määrää uudelleen toiminnot ajoituksen kannalta herkässä järjestyksessä.

Muuta neuvoa-antavaa lautakuntaa

Jos ohjelmisto on osa suurempaa sertifioitua järjestelmää (esim. avioniikka, ydinreaktorin valvonta), koodin muuttaminen voi edellyttää muutoksen valvontaelimen hyväksyntää. Hallitus arvioi korjaussuunnitelman, riskinarvioinnin, uudelleenkäytön strategian ja näytön validoinnista. Korjausperusteen ja testitulosten dokumentointi toimialan standardien mukaisessa muodossa (esim. DO-178C, IEC 61508) takaa auditoitavuuden.

Päätelmät

Refaktorointi ei ole päämäärä itsessään.Se on keino pitää kriittinen tekninen ohjelmisto turvallinen, ylläpidettävissä ja kestävä. Soveltamalla insinöörit asteittain muutoksia, tiukka testaus ja käyttöönotto strategioita, jotka minimoivat riskit, insinöörit voivat vähentää teknistä velkaa aiheuttamatta seisokkia. Avain on käsitellä refaktorointia samalla kurilla kuin kaikki muut muutokset turvallisuuden kriittinen ympäristö: suunnitelma perusteellisesti, testata pakkomielteisesti, ja aina olla rollback valmis. Kun tehdään oikein, refaktorointi muuttaa hauras koodi vahva koodi keskeyttämättä järjestelmiä, jotka yhteiskunta riippuu.