Kort TID ETTER Y2K gjorde vi vitser om » neste Opp, Y2038!»men da følte det seg en evighet i fremtiden og sannsynligvis være andres problem. Nå som vi er halvveis der, og vi allerede har nådd Det Punktet Der y2038-problemer kan forårsake programvarefeil, er det en god mulighet til å begynne å planlegge For Y2038. For eksempel kan programvare allerede ha problemer med å jobbe med 20 års sertifikatlevetid eller 20 års boliglån, og hyppigheten av disse problemene vil bare øke når Vi kommer nærmere Y2038. På Akamai kjører Vi allerede strategisk målrettet intern planlegging og testing For Y2038, og det virker sannsynlig at omfanget av dette arbeidet vil fortsette å vokse de neste 19 årene, da denne viktige innsatsen øker i haster.

Svært lite gikk galt 1. januar 2000 for oss (kort Av Noen Javascript På En Akamai markedsføring nettsted viser «19100» som gjeldende dato!), men en ting som blir savnet er at den begrensede globale effekten den kvelden skyldtes to faktorer: 1) mengden avansert forberedelse som ble gjort; 2) mange «Y2K problemer» faktisk skjedde år i forveien i stedet for under roll-over seg selv. Leap sekunder er på noen måter skumlere enn dato format problemer i at de er vanskeligere å teste for og mye mindre av virkningen skjer på forhånd. DET er fare for at mangelen PÅ virkninger AV Y2K kan føre til at organisasjoner og teknologer underforbereder Seg For Y2038. Det er også vanskeligere å forklare «Y2038» for å legge folk ENN Y2K, noe som potensielt gjør det vanskeligere å prioritere og fokusere avansert arbeid. Det store antallet innebygde Tingenes Internett (Iot) – enheter som blir allestedsnærværende i vårt miljø, gjør også den sannsynlige risikoen og potensielle effekten betydelig høyere For Y2038 enn DEN var FOR Y2K. Et lager hadde to automatiserte jobber: en som så etter paller med utgåtte varer og sendte dem til avhending, og en annen som så etter lavt lager og bestilte mer av et produkt. Hermetiserte tomater var det første produktet som hadde utløpsdatoer som begynte å krysse inn i år 2000, og EN Y2K-bug regisserte en gaffeltruckoperatør for å avhende disse tomatene (utløper i 1900!) som de kom. Systemet identifiserte da at det var lite lager på hermetiske tomater og ville bestille mer. Noen uker senere ville de ankomme, og noen dager senere ville gaffeltruckoperatøren bli sendt for å avhende dem. Denne syklusen fortsatte til gaffeltruckoperatøren endelig la merke til noe galt og eskalerte problemet. Det er sannsynlig at Noen Av De første y2038-problemene vil være ganske like i naturen.Vår første erfaring Med y2038 planlegging (foruten å se sjokk fra folk ved å høre bekymringer blir reist som ved første lyd 19 år unna) er at en inkrementell og fokusert tilnærming er nødvendig på dette stadiet. Mye mer involvert og omfattende programmer vil sikkert være nødvendig noen år nedover veien. I denne innledende fasen, noen områder å fokusere på inkluderer: 1) programvare håndtere fremtidige tider og datoer; 2) on-the-wire melding og filformater; 3) enheter med lang utplassert levetid, og deres avhengigheter. Selvfølgelig når vi kommer nærmere, vil det bli kritisk å begynne å fokusere på bredere sett med systemer, inkludert å sikre at De kan håndtere å krysse y2038-overgangen trygt.

Programvare som omhandler fremtidige datoer

kanskje det viktigste området å fokusere på i utgangspunktet er programvare som omhandler datoer i fremtiden, for eksempel for håndtering Av x. 509 sertifikater eller for økonomisk planlegging. Det er mange dato-og tidsformatrepresentasjoner, ikke alle som vil ha Et Y2038-problem. For eksempel valgte programvare som måtte håndtere tider i de siste århundrene (godt før 1970) ofte forskjellige dato-og klokkeslettrepresentasjoner. Men ved testing Av Tilfeller Av x. 509-sertifikater (for eksempel brukt TIL HTTPS) og sertifikatmyndigheter (CAs) har vi funnet mange programvareproblemer i laboratoriet som begynner å oppstå med sertifikater og CAs utløper forbi Y2038.OpenSSL har spesielt flere tidsformater, MED ASN1_UTCTIME som har en grense I Y2049 (et tydelig problem å planlegge for Fra Y2038), så bruk asn1_time-funksjonene som gir kompatibilitet med alle tidsområder. Konvertere ganger ut fra et bibliotek Som OpenSSL ut i 32-bit time_t er et ekstra område som sannsynligvis vil ha problemer.I mange av disse tilfellene har det vært mulig å løse problemene ved å portere og kompilere eldre programvare for 64-biters arkitekturer (f.eks. å flytte fra et 32-biters heltall time_t til en 64-biters time_t). I andre tilfeller har det vært behov for mer omfattende endringer, spesielt når tider blir kastet inn i heltall for matte eller når meldingstrådformater blir involvert eller når verdier lagres i databaser. Ved testing og fastsetting av støtte for 20-årige CAs er det en ting som viste seg at nedstrømsavhengigheter også kommer inn i spill. For eksempel, hvis en dato 20 år i fremtiden blir matet inn i et loggingssystem eller overvåkingssystem, og hvis de i sin tur mates inn i varslingssystemer eller rapporteringsdatabaser eller klargjøringssystemer, kan de også alle trenge reparasjoner.

on-the-wire melding og filformater

som nevnt ovenfor, når 32-bits tidsstempler er satt inn i meldinger, databaser, eller filformater virkningen kan strekke seg langt utover et bestemt system. Dette er også systemer med eksterne avhengigheter der mer avansert planlegging er ofte nødvendig som interaksjoner krysse systemgrenser. For disse samlingene av interoperativsystemer må endringer kanskje utgis i en bestemt rekkefølge, og bakoverkompatibilitet kommer ofte til spill. Videre, hvis det er enten formelt eller uformelt standardiserte protokoller som bruker 32-bit epoch tidsstempelverdier i meldinger, kan enhver migrasjon eller løsning være basert på å fikse standarden. Som sådan blir disse viktige å bekymre seg for som med en avhengighetskjede som:

1. Oppdater protokoll / standarder for å støtte post-Y2038 tidsstempler.
2. Implementere støtte for oppdatert standard i programvarebiblioteker.
3. Få ny versjon av biblioteker innlemmet i programvarepakker.
4. Få programvarepakker inkludert i nytt fraktprodukt.

Så hvis hver av disse tar noen år og fraktproduktet har lang levetid, kan de lange ledetidene her allerede være et problem.

Enheter med lang utplassert levetid, og deres avhengigheter

et annet område å begynne å fokusere på tidlig er enheter med lang distribusjon levetid. Som nettopp nevnt, er det også viktig å følge gjennom de eksterne avhengighetene disse enhetene har. Innebygde enheter som leveres med 32-biters maskinvare, kan heller ikke ha en enkel løsning på «bare kompilere for en 64-biters time_t» via en programvareoppdatering, eller det kan ha uakseptabel ytelsespåvirkning.Tilkoblede biler og Andre iot-enheter er sannsynligvis et område med spesiell bekymring, men jeg er sikker på at det finnes mange andre lignende typer enheter og applikasjoner. For eksempel, gitt dagens trender er det sannsynlig at over 10% av biler som selges i Dag vil fortsatt være i drift I Y2038, og med økning i kjøretøy alder og antall biler på veien dette kan være enda høyere. Hvis det tar noen år for frakt biler å være Generelt y2038 kompatibel, med dagens (og økende) distribusjon av motorkjøretøyer aldre kan vi ende opp med en betydelig brøkdel av biler med potensial til å ha alvorlige problemer i nitten år. Det samme mønsteret finnes sannsynligvis også i noen andre bransjer, for Eksempel I Forbrukerelektronikk (for eksempel hjemmespillkonsoller og smart-tv) hvor enheter kan sendes med 20 + års CA-sertifikater forhåndsinstallert.

Enheter med lang utplassert levetid kan kreve mer omfattende testing av både enheten og dens avhengigheter, for eksempel testing av at operativsystemet og programvaren fortsetter å fungere skikkelig før, under Og etter Y2038 – overgangspunktet.

Godt Nytt År!

Y2038-problemet er i en lignende kategori Som IPv6: det er en multi-tiår utrulling som i det generelle tilfellet Er Viktig, men ikke Ennå Presserende (per Eisenhower-Matrisen). Fra dette perspektivet er nå like god tid som noen å begynne å planlegge, triaging og testing før det blir presserende (eller for sent). Fokuser først på programvare som omhandler fremtidige datoer, on-the-wire melding og filformater, og enheter med lang utplassert levetid. Bruk deretter erfaringen fra det første fokuset til å bygge et mer omfattende program de kommende årene. Uansett, sett en minimumslinje og begynn å sørge for at ny programvare, systemer, protokoller og produkter du bygger og distribuerer, ikke introduserer y2038-problemer, og flagg bekymringer når du ser 32-biters tidsstempler-siden-unix-epoken inkludert i nye design.Erik Nygren Er Fellow Og Sjefsarkitekt I Akamais Plattformtekniske organisasjon. Han feirer sitt 20-årsjubileum På Akamai i juni.

Takk til flere folk På Akamai for deres bidrag til denne artikkelen.

mens forholdsregler er tatt i utarbeidelsen av dette dokumentet, Akamai Technologies, Inc. påtar seg intet ansvar for feil, utelatelser, eller for skader som følge av bruk av informasjonen her. Informasjonen her kan endres uten varsel. Akamai og akamai wave-logoen er registrerte varemerker eller servicemerker i Usa (Reg. U. S. Pat. & Tm. Ut). Publisert 10.Januar 2019.