pian Y2K: n jälkeen vitsailimme ”next up, Y2038!”mutta silloin se tuntui ikuisuudelta tulevaisuudessa ja oli todennäköisesti jonkun toisen ongelma. Nyt kun olemme puolivälissä, ja olemme jo saavuttaneet pisteen, jossa Y2038-ongelmat voivat aiheuttaa ohjelmistovikoja, on hyvä tilaisuus aloittaa y2038: n suunnittelu. Esimerkiksi ohjelmistoilla voi jo olla ongelmia, jotka toimivat 20-vuotisen sertifikaatin elinaikana tai 20-vuotisten asuntolainojen kanssa, ja näiden kysymysten taajuus vain kasvaa, kun pääsemme lähemmäs Y2038: aa. Akamaissa suoritamme jo strategisesti kohdennettua sisäistä suunnittelua ja testausta Y2038: lle, ja näyttää todennäköiseltä, että tämän työn laajuus kasvaa edelleen seuraavien 19 vuoden aikana, kun tämä tärkeä ponnistus kasvaa kiireellisyydessä.

hyvin vähän meni pieleen tammikuun 1, 2000 meille (lukuun ottamatta joitakin Javascript on a Akamai markkinointi sivusto näyttää ”19100” kuin nykyinen päivämäärä!), mutta yksi asia, joka jää huomaamatta, on se, että rajallinen maailmanlaajuinen vaikutus tuona iltana johtui kahdesta tekijästä: 1) edistyneen valmistelun määrä, joka tehtiin; 2) monet ”Y2K-ongelmat” tapahtuivat todellisuudessa vuosia etukäteen eikä itse kaatumisen aikana. Karkaussekunnit ovat tietyllä tavalla pelottavampia kuin päivämäärämuotoiset kysymykset, koska niitä on vaikeampi testata ja paljon vähemmän vaikutuksia tapahtuu etukäteen. On olemassa vaara, että Y2K: n vaikutusten puute voi aiheuttaa sen, että organisaatiot ja teknologiat alivalmiutuvat Y2038: aan. On myös vaikeampi selittää” Y2038 ” maallikoille kuin Y2K, mikä mahdollisesti vaikeuttaa kehittyneen työn priorisointia ja keskittymistä. Suuri määrä sulautettuja Esineiden Internet (IoT) laitteita tulossa kaikkialla ympäristössämme tekee todennäköinen riski ja potentiaalinen vaikutus huomattavasti suurempi Y2038 kuin se oli Y2K.

ensimmäinen kokemuksemme Y2038-suunnittelusta (sen lisäksi, että näemme järkytyksen ihmisiltä, kun he kuulevat huolenaiheita, jotka tulevat esiin 19 vuoden päästä) on, että tässä vaiheessa tarvitaan asteittaista ja kohdennettua lähestymistapaa. Paljon enemmän mukana ja kattavia ohjelmia varmasti tarvitaan joitakin vuosia tiellä. Tässä alkuvaiheessa, jotkut alueet keskittyä ovat: 1) ohjelmisto käsittelee tulevia aikoja ja päivämääriä; 2) on-the-wire viesti ja tiedostomuodot; 3) laitteet, joilla on pitkä käyttöikä, ja niiden riippuvuudet. Tietenkin kun pääsemme lähemmäksi, tulee kriittiseksi alkaa keskittyä laajempiin järjestelmiin, mukaan lukien sen varmistaminen, että ne voivat käsitellä y2038-siirtymän turvallisesti.

ohjelmisto, joka käsittelee tulevia päivämääriä

ehkä tärkein alue, johon kannattaa aluksi keskittyä, on ohjelmisto, joka käsittelee tulevaisuuden päivämääriä, kuten X. 509-varmenteiden käsittelyä tai taloussuunnittelua. On olemassa monia päivämäärä ja aika formaatti esityksiä, jotka kaikki eivät ole Y2038 ongelma. Esimerkiksi ohjelmistot, joiden piti käsitellä menneiden vuosisatojen aikoja (paljon ennen vuotta 1970), valitsivat usein erilaisia ajankohta-ja ajankuvauksia. Testattaessa X. 509-varmenteita (kuten HTTPS-varmenteita) ja varmenneviranomaisia (CAS) olemme kuitenkin havainneet laboratoriossa lukuisia ohjelmistoon liittyviä ongelmia, joita alkaa ilmetä Y2038: n jälkeen päättyvissä varmenteissa ja CAs: issä.

OpenSSL erityisesti on useita aikamuotoja, asn1_utctime on raja y2049 (erillinen kysymys suunnitella y2038), joten käytä ASN1_TIME toiminnot tarjoavat yhteensopivuuden kaikkien alueiden aika. Muunnetaan ajat pois kirjastosta, kuten OpenSSL ulos 32-bittiseksi time_t: ksi, on lisäalue, jolla on todennäköisesti ongelmia.

monissa näistä tapauksista ongelmat on voitu ratkaista yksinkertaisesti siirtämällä ja kokoamalla vanhoja ohjelmistoja 64-bittisille arkkitehtuureille (esim.siirryttäessä 32-bittisestä kokonaisluvusta time_t 64-bittiseen time_t: hen). Muissa tapauksissa on tarvittu laajempia muutoksia, varsinkin kun ajat heitetään kokonaislukuihin matematiikkaa varten tai kun viestilankamuodot tulevat mukaan tai kun arvot tallennetaan tietokantoihin. 20 vuoden CAs-tuen testaamisessa ja kiinnittämisessä yksi asia, joka näkyi, on se, että myös loppupään riippuvuudet tulevat kuvaan. Jos esimerkiksi 20 vuoden kuluttua päivämäärä syötetään kirjausjärjestelmään tai seurantajärjestelmään, ja jos nämä vuorollaan syötetään hälytysjärjestelmiin tai raportointitietokantoihin tai varausjärjestelmiin, ne kaikki saattavat myös tarvita korjauksia.

on-the-wire-Sanoma ja tiedostomuodot

kuten edellä on mainittu, kun 32-bittisiä aikaleimoja laitetaan viesteihin, tietokantoihin tai tiedostomuotoihin, vaikutus voi ulottua selvästi tietyn järjestelmän ulkopuolelle. Nämä ovat myös järjestelmiä, joissa on ulkoisia riippuvuuksia ja joissa tarvitaan usein kehittyneempää suunnittelua, kun vuorovaikutus ylittää järjestelmän rajat. Näissä yhteentoimivien järjestelmien kokoelmissa muutokset saatetaan joutua julkaisemaan tietyssä järjestyksessä ja taaksepäin yhteensopivuus tulee usein kuvaan. Lisäksi, jos on olemassa joko muodollisesti tai epävirallisesti standardoituja protokollia, jotka käyttävät 32-bittisiä epoch-aikaleiman arvoja viesteissä, mikä tahansa siirtymä tai korjaus voi perustua standardin vahvistamiseen. Sellaisinaan näistä tulee tärkeitä huolehtia kuin riippuvuusketjussa, kuten:

1. Päivitä protokolla / standardit tukemaan y2038: n jälkeisiä aikaleimoja.
2. toteuta päivitetyn standardin tuki ohjelmakirjastoissa.
3. Hanki ohjelmistopaketteihin liitetyt kirjastojen uudet versiot.
4. Hanki ohjelmistopaketit mukaan uuteen toimitustuotteeseen.

sitten jos jokainen näistä kestää muutaman vuoden ja laivaustuotteella on pitkä käyttöikä, niin pitkät toimitusajat täällä voivat jo olla ongelma.

laitteet, joiden käyttöaika on pitkä, ja niiden riippuvuudet

toinen alue, johon kannattaa alkaa keskittyä aikaisin, on laitteet, joiden käyttöaika on pitkä. Kuten juuri mainittiin, seuraavat ulkoiset riippuvuudet näillä laitteilla on myös tärkeää. Sulautettujen laitteiden toimitus 32-bittinen laitteisto voi myös ole helppo korjata ”vain kääntää varten 64-bittinen time_t” kautta ohjelmistopäivitys, tai näin voi olla hyväksyttävää suorituskykyä vaikutusta.

liitetyt autot ja muut IoT-laitteet ovat todennäköisesti erityishuolenaihe, mutta eiköhän vastaavia laitteita ja sovelluksia ole monia muitakin. Esimerkiksi nykytrendien perusteella on todennäköistä, että yli 10 prosenttia myytävistä autoista toimii edelleen Y2038: ssa, ja ajoneuvojen iän ja tiellä olevien ajoneuvojen määrän kasvaessa tämä voi olla vielä suurempi. Jos se kestää muutaman vuoden merenkulun autojen on yleensä Y2038 yhteensopiva, nykyisen (ja kasvava) Jakelu moottoriajoneuvojen ikäryhmissä saatamme päätyä merkittävä murto-osa autojen potentiaali on vakavia ongelmia yhdeksäntoista vuotta. Tämä sama kuvio todennäköisesti esiintyy myös joillakin muilla toimialoilla, kuten kulutuselektroniikassa (kuten kotipelikonsoleissa ja älytelevisioissa), jossa laitteet voidaan lähettää 20+ vuoden CA-sertifikaateilla esiasennettuna.

laitteet, joiden käyttöaika on pitkä, voivat vaatia sekä laitteen että sen riippuvuuksien kattavampaa testausta, kuten sen testaamista, että käyttöjärjestelmä ja ohjelmisto toimivat edelleen asianmukaisesti ennen Y2038-siirtymäpistettä, sen aikana ja sen jälkeen.

Hyvää Uutta Vuotta!

Y2038: n emissio on samaa luokkaa kuin IPv6: se on usean vuosikymmenen roll-out, että yleensä on tärkeää, mutta ei vielä kiireellistä (kohti Eisenhower matriisi). Tästä näkökulmasta nyt on hyvä aika aloittaa suunnittelu, triaging, ja testaus ennen kuin se tulee kiireellinen (tai liian myöhään). Keskity ensin ohjelmistoihin, jotka käsittelevät tulevia päivämääriä, on-the-wire-viestin ja tiedostomuotoja, ja laitteisiin, joilla on pitkä käyttöikä. Seuraavaksi, käyttää kokemusta alkuperäisestä keskittyä rakentaa kattavampi ohjelma tulevina vuosina. Siitä huolimatta, aseta vähimmäispalkki ja varmista, että uudet ohjelmistot, järjestelmät, protokollat ja tuotteet, joita rakennat ja otat käyttöön, eivät tuo Y2038-ongelmia ja merkitse huolenaiheita, kun näet 32-bittiset aikaleimat-Unix-ajasta lähtien-sisältyvät uusiin malleihin.

Erik Nygren on kollega ja pääarkkitehti Akamain Platform Engineering-organisaatiossa. Hän juhlii 20-vuotishääpäiväänsä Akamaissa kesäkuussa.

Kiitos monelle Akamain väelle heidän panoksestaan tähän artikkeliin.

vaikka tämän asiakirjan valmistelussa on ryhdytty varotoimiin, Akamai Technologies, Inc. ei ole vastuussa virheistä, laiminlyönneistä tai vahingoista, jotka johtuvat tässä olevien tietojen käytöstä. Tässä olevat tiedot voivat muuttua ilman erillistä ilmoitusta. Akamai ja Akamai wave-logo ovat rekisteröityjä tavaramerkkejä tai palvelumerkkejä Yhdysvalloissa (Reg. U. S. Pat. & Tm. Pois). Julkaistu 10. Tammikuuta 2019.