Энэ бол алдаанууд заримдаа үнэхээр гайхалтай илрэлүүдтэй байдаг тухай интернетээс авсан түүхүүдийн түүвэр юм. Магадгүй танд бас хэлэх зүйл байгаа байх.
Ванилийн зайрмагны машины харшил
Мэдээжийн хэрэг үргэлж хариулт байдаггүй, хэчнээн хол зөрүүтэй мэт санагдаж байсан ч бодит байдал хэвээр байдгийг ойлгодог инженерүүдэд зориулсан түүх. Женерал Моторс Корпорацийн Понтиак хэлтэст дараах гомдол ирсэн байна.
Би чамд хоёр дахь удаагаа бичиж байгаа бөгөөд хариу өгөөгүйд чинь би чамайг буруутгахгүй, учир нь энэ нь галзуу сонсогдож байна. Манай гэр бүл орой бүр оройн хоолны дараа зайрмаг иддэг уламжлалтай. Зайрмагны төрөл бүр өөрчлөгддөг бөгөөд оройн хоолны дараа гэр бүлээрээ аль зайрмаг авахаа сонгодог бөгөөд дараа нь би дэлгүүрт очдог. Би саяхан шинэ Pontiac худалдаж авсан бөгөөд тэр цагаас хойш зайрмаг авах аялал маань асуудал болоод байна. Харж байна уу, ванилийн зайрмаг аваад дэлгүүрээс ирэх болгонд машин асахгүй. Өөр зайрмаг авчирвал машин ямар ч асуудалгүй асдаг. Хичнээн тэнэг сонсогдож байсан ч би ноцтой асуулт асуумаар байна: "Намайг ванилийн зайрмаг авчрахад эхэлдэггүй, өөр амттай зайрмаг авчрахад амархан эхэлдэг Понтиак юу вэ?"
Таны төсөөлж байгаачлан хэлтсийн ерөнхийлөгч захидлын талаар эргэлзэж байсан. Гэсэн хэдий ч ямар ч байсан би инженерээ явуулж шалгасан. Үзэсгэлэнт газар амьдардаг, баян чинээлэг, боловсролтой нэгэн залуу түүнтэй уулзсанд нь гайхаж байв. Тэд оройн хоолны дараа шууд уулзахаар тохиролцож, хоёулаа дэлгүүрт зайрмаг идэхээр боллоо. Тэр орой ваниль байсан бөгөөд тэднийг буцаж машиндаа ирэхэд асахгүй байв.
Инженер дахиад гурван орой ирлээ. Анх удаа зайрмаг нь шоколад байсан. Машин хөдөллөө. Хоёр дахь удаагаа гүзээлзгэнэтэй зайрмаг байсан. Машин хөдөллөө. Гурав дахь орой тэр ваниллин авахыг хүсэв. Машин асаагүй.
Ухаалаг үндэслэлээр инженер машин нь ванилийн зайрмагнаас харшилтай гэдэгт итгэхээс татгалзав. Тиймээс машины эзэнтэй тохиролцож, асуудлыг шийдвэрлэх арга замыг олох хүртэл айлчлалаа үргэлжлүүлэх болно. Замдаа тэр тэмдэглэл хөтөлж эхлэв: тэр бүх мэдээлэл, өдрийн цаг, бензиний төрөл, дэлгүүрээс ирэх, буцах цаг гэх мэтийг бичжээ.
Инженер удалгүй машины эзэн ванилийн зайрмаг худалдаж авахад бага цаг зарцуулдаг болохыг ойлгов. Шалтгаан нь дэлгүүрт байгаа барааны зохион байгуулалт байсан. Ваниль зайрмаг нь хамгийн алдартай байсан бөгөөд олоход хялбар болгох үүднээс дэлгүүрийн урд талд тусдаа хөлдөөгчид хадгалдаг байв. Бусад бүх сортууд дэлгүүрийн арын хэсэгт байсан бөгөөд зөв сортыг олж, төлөхөд илүү их цаг зарцуулсан.
Одоо инженерийн хувьд асуулт гарч ирэв: хөдөлгүүр унтарснаас хойш бага хугацаа өнгөрсөн бол яагаад машин асахгүй байна вэ? Асуудал нь ванилийн зайрмаг биш цаг хугацаа байсан тул инженер хурдан хариултыг олсон: энэ бол хийн цоож байсан. Энэ нь орой бүр тохиолддог байсан ч машины эзэн зайрмаг хайхад илүү их цаг зарцуулах үед хөдөлгүүр нь хангалттай хөргөж, амархан асдаг байв. Мөн тэр хүн ванилийн зайрмаг худалдаж авахад хөдөлгүүр хэт халуун хэвээр байсан бөгөөд хийн түгжээ нь уусч амжаагүй байв.
Ёс суртахуун: Бүр галзуу асуудлууд ч заримдаа бодитой байдаг.
Сүйрэл Bandicoot
Үүнийг мэдрэх нь өвдөж байна. Програмист хүний хувьд та өөрийнхөө кодыг нэгдүгээрт, хоёрдугаарт, гуравдугаарт... буруутгаж, арван мянгатын хаа нэгтээ хөрвүүлэгчийг буруутгаж дасдаг. Жагсаалтын дараа та тоног төхөөрөмжийг буруутгаж байна.
Техник хангамжийн алдааны тухай миний түүх энд байна.
Crash Bandicoot тоглоомын хувьд би санах ойн картанд ачаалж хадгалах код бичсэн. Ийм царайлаг тоглоом хөгжүүлэгчийн хувьд энэ нь цэцэрлэгт хүрээлэнгээр зугаалахтай адил байсан: ажил хэдэн өдөр болно гэж би бодсон. Гэсэн хэдий ч би зургаан долоо хоногийн турш кодыг дибаг хийж дуусгасан. Замдаа би бусад асуудлуудыг шийдэж байсан ч хэдэн өдөр тутам энэ код руу хэдхэн цагийн турш буцаж ирэв. Энэ нь зовлон байсан.
Шинж тэмдэг нь иймэрхүү харагдаж байв: Та тоглоомын одоогийн дамжуулалтыг хадгалж, санах ойн карт руу нэвтрэх үед бүх зүйл бараг үргэлж хэвийн байдаг ... Гэхдээ заримдаа унших, бичих ажиллагаа тодорхой шалтгаангүйгээр тасалддаг. Богино бичлэг нь санах ойн картыг гэмтээдэг. Тоглогч аврах гэж оролдохдоо аварч чадаагүй төдийгүй газрын зургийг устгадаг. Новш.
Хэсэг хугацааны дараа манай Sony-ийн продюсер Конни Бус сандарч эхлэв. Бид энэ алдаатай тоглоомыг илгээж чадаагүй бөгөөд зургаан долоо хоногийн дараа би асуудал юунаас болж байгааг ойлгоогүй. Коннигоор дамжуулан бид PS1-ийн бусад хөгжүүлэгчидтэй холбоо барьсан: үүнтэй төстэй зүйлтэй тулгарсан хүн байна уу? Үгүй Санах ойн карттай холбоотой асуудал хэнд ч байгаагүй.
Дибаг хийх ямар ч санаа байхгүй үед "хувааж, ялах" цорын ганц арга зам үлдэнэ: алдаатай програмаас харьцангуй жижиг хэсэг үлдэж, асуудал үүсгэсээр байх хүртэл илүү олон кодыг устга. Өөрөөр хэлбэл, та алдаа агуулсан хэсэг үлдэх хүртэл програмыг хэсэг хэсгээр нь таслана.
Гэхдээ гол зүйл бол видео тоглоомыг хэсэгчлэн таслах нь маш хэцүү байдаг. Хэрэв та таталцлын хүчийг дуурайдаг кодыг устгасан бол үүнийг хэрхэн ажиллуулах вэ? Эсвэл дүр зурах уу?
Тиймээс бид бүхэл бүтэн модулиудыг ашигтай зүйл хийж байгаа мэт дүр эсгэдэг бүдүүвчүүдээр солих ёстой, гэхдээ үнэндээ алдаа агуулаагүй маш энгийн зүйлийг хийдэг. Тоглоомыг ядаж ажиллахын тулд бид ийм таяг бичих ёстой. Энэ бол удаан бөгөөд өвдөлттэй үйл явц юм.
Товчхондоо би үүнийг хийсэн. Тоглоомыг ажиллуулах системийг тохируулах, дүрслэх техник хангамжийг эхлүүлэх гэх мэт анхны кодтой үлдэх хүртэл би улам олон тооны кодыг устгасан. Мэдээжийн хэрэг, энэ үе шатанд би хадгалах, ачаалах цэс үүсгэж чадахгүй байсан, учир нь би бүх график кодын stub үүсгэх шаардлагатай болно. Гэхдээ би (үл үзэгдэх) хадгалах, ачаалах дэлгэцийг ашиглан хэрэглэгч мэт дүр эсгэж, хадгалахыг хүсч, дараа нь санах ойн карт руу бичиж болно.
Энэ нь надад дээрх асуудалтай хэвээр байгаа жижиг код үлдээсэн - гэхдээ энэ нь санамсаргүй тохиолдсон хэвээр байна! Ихэнхдээ бүх зүйл хэвийн ажилладаг байсан ч хааяа алдаа гардаг. Би бараг бүх тоглоомын кодыг устгасан боловч алдаа нь амьд хэвээр байсан. Энэ нь эргэлзээтэй байсан: үлдсэн код нь үнэндээ юу ч хийсэнгүй.
Хэзээ нэгэн цагт, магадгүй өглөөний гурван цагийн орчимд нэг бодол орж ирэв. Унших, бичих (оролт/гаралт) үйлдлүүд нь нарийн гүйцэтгэлийн хугацааг хамардаг. Та хатуу диск, санах ойн карт эсвэл Bluetooth модультай ажиллах үед унших, бичих үүрэгтэй доод түвшний код нь цагийн импульсийн дагуу үүнийг хийдэг.
Цагийн тусламжтайгаар процессортой шууд холбогдоогүй төхөөрөмжийг процессор дээр ажиллаж буй кодтой синхрончлох болно. Цаг нь дамжуулах хурд буюу өгөгдөл дамжуулах хурдыг тодорхойлдог. Хэрэв цаг хугацааны хувьд төөрөгдөл байгаа бол техник хангамж эсвэл програм хангамж эсвэл хоёулаа андуурч байна. Мөн энэ нь маш муу, учир нь өгөгдөл гэмтэх боломжтой.
Хэрэв манай кодын ямар нэг зүйл цаг хугацааг төөрөлдүүлж байвал яах вэ? Би туршилтын програмын кодонд үүнтэй холбоотой бүх зүйлийг шалгаж үзээд бид PS1-д програмчлагдсан таймерыг 1 кГц (секундэд 1000 хачиг) болгон тохируулсныг анзаарсан. Энэ нь маш их зүйл бөгөөд анхдагчаар консол эхлэхэд 100 Гц давтамжтайгаар ажилладаг. Мөн ихэнх тоглоомууд энэ давтамжийг ашигладаг.
Тоглоомын хөгжүүлэгч Энди хөдөлгөөнийг илүү нарийвчлалтай тооцоолохын тулд таймерыг 1 кГц болгож тохируулсан. Энди хэт давах хандлагатай байдаг бөгөөд хэрэв бид таталцлын хүчийг дуурайвал бид үүнийг аль болох нарийвчлалтай хийдэг!
Гэхдээ таймерыг хурдасгах нь програмын нийт цаг хугацаа, улмаар санах ойн картын дамжуулах хурдыг зохицуулдаг цагийг ямар нэгэн байдлаар нөлөөлсөн бол яах вэ?
Би таймерын кодыг тайлбарлав. Алдаа дахин гарсангүй. Гэхдээ энэ нь алдаа санамсаргүй тохиолдсон тул бид үүнийг зассан гэсэн үг биш юм. Хэрэв би азтай байсан бол яах вэ?
Хэдэн өдрийн дараа би туршилтын программыг дахин туршиж үзсэн. Алдаа дахин давтагдсангүй. Би тоглоомын бүрэн кодын сан руу буцаж очоод хадгалах, ачаалах кодыг өөрчилснөөр програмчлагдсан таймер санах ойн карт руу орохын өмнө анхны утгаараа (100 Гц) дахин тохируулагдаж, дараа нь 1 кГц болгон дахин тохируулагдсан. Дахиад осол гарсангүй.
Гэхдээ яагаад ийм зүйл болсон бэ?
Би туршилтын хөтөлбөрт дахин орлоо. Би 1 кГц таймерын тусламжтайгаар алдаа гарахад ямар нэгэн хэв маягийг олохыг хичээсэн. Эцэст нь хэн нэгэн PS1 хянагчаар тоглоход алдаа гардаг болохыг би анзаарсан. Би өөрөө үүнийг хийх нь ховор байсан тул хадгалах болон ачаалах кодыг туршиж үзэхэд яагаад хянагч хэрэгтэй байна вэ? - Би энэ хараат байдлыг анзаараагүй. Гэтэл нэг өдөр манай нэг зураач намайг шалгалтаа дуусгахыг хүлээж байсан - тэр үед би харааж байсан байх, - гэж сандарсандаа гартаа байгаа контроллероо эргүүлэв. Алдаа гарсан байна. "Хүлээгээрэй, юу?!" За, дахиад хий!"
Эдгээр хоёр үйл явдал хоорондоо уялдаатай байгааг мэдээд би алдааг хялбархан давтаж чадсан: би санах ойн карт руу бичлэг хийж, хянагчийг хөдөлгөж, санах ойн картыг сүйтгэсэн. Миний хувьд энэ нь техник хангамжийн алдаа мэт санагдсан.
Би Конни дээр ирээд нээлтийнхээ тухай хэлэв. Тэрээр PS1-ийг зохион бүтээсэн инженерүүдийн нэгэнд энэ мэдээллийг дамжуулав. "Боломжгүй" гэж тэр хариулав, "энэ нь техник хангамжийн асуудал байж болохгүй." Би Конниг бидэнтэй ярилцахыг хүссэн.
Инженер намайг дуудаж, бид түүний эвдэрсэн англи хэлээр, миний (маш) эвдэрсэн япон хэлээр маргалдсан. Эцэст нь би "Хянагчийг хөдөлгөхөд алдаа гардаг 30 мөрийн туршилтын хөтөлбөрөө явуулъя." Тэр зөвшөөрөв. Энэ нь цагаа дэмий үрсэн, шинэ төсөл дээр ажиллаж маш завгүй байгаа ч бид Sony-ийн маш чухал хөгжүүлэгч учраас бууж өгөх болно гэж хэлсэн. Би шалгалтын програмаа цэвэрлээд түүн рүү явуулсан.
Маргааш орой нь (бид Лос-Анжелес, тэр Токиод байсан) над руу утасдаж, уучлалт гуйсан. Энэ нь техник хангамжийн асуудал байсан.
Алдаа нь яг юу байсныг би мэдэхгүй, гэхдээ Sony-ийн төв оффис дээр миний сонссоноор хэрэв та таймерыг хангалттай өндөрт тохируулсан бол энэ нь таймер болорын ойролцоо эх хавтан дээрх бүрэлдэхүүн хэсгүүдэд саад болж байна. Тэдгээрийн нэг нь санах ойн картын дамжуулах хурдны хянагч байсан бөгөөд энэ нь хянагчдад дамжуулах хурдыг тохируулдаг байв. Би инженер биш болохоор ямар нэг юм будлиулчихсан байж магадгүй.
Гэхдээ хамгийн гол нь эх хавтан дээрх бүрэлдэхүүн хэсгүүдийн хооронд хөндлөнгийн оролцоо байсан. Мөн хянагчийн порт болон 1 кГц давтамжтай таймер бүхий санах ойн картын портоор нэгэн зэрэг өгөгдөл дамжуулах үед битүүд алдаж, өгөгдөл алдагдаж, карт гэмтсэн.
Муу үхэр
1980-аад онд миний зөвлөгч Сергей PDP-1800-ийн Зөвлөлтийн клон болох SM-11-ийн программ хангамжийг бичсэн. Энэхүү микрокомпьютерийг ЗХУ-ын тээврийн чухал зангилаа болох Свердловск хотын ойролцоох төмөр замын буудалд саяхан суурилуулжээ. Шинэ систем нь вагон, ачааны урсгалыг чиглүүлэхэд зориулагдсан. Гэхдээ энэ нь санамсаргүй эвдрэл, эвдрэлд хүргэсэн ядаргаатай алдаа агуулсан байв. Орой нь хэн нэгэн гэртээ харих үед уналт үргэлж тохиолддог. Гэвч маргааш нь сайтар шалгаж үзсэн ч компьютер бүх гарын авлагын болон автомат туршилтуудад зөв ажилласан. Энэ нь ихэвчлэн уралдааны нөхцөл эсвэл тодорхой нөхцөлд тохиолддог бусад өрсөлдөөний алдааг илэрхийлдэг. Шөнө орой болсон дуудлагуудаас залхсан Сергей энэ бүхний учрыг олохоор шийдээд юуны өмнө төвлөрсөн талбайд ямар нөхцөл байдал компьютер эвдэрсэнийг ойлгох хэрэгтэй.
Эхлээд тэрээр тайлбарлаагүй бүх уналтын статистикийг цуглуулж, огноо, цаг хугацааны графикийг бүтээсэн. Загвар нь тодорхой байсан. Хэдэн өдрийн турш ажигласны дараа Сергей ирээдүйн системийн эвдрэлийн цагийг хялбархан таамаглаж чадна гэдгээ ойлгов.
Удалгүй тэр станц Украйны хойд хэсэг, Оросын баруун хэсгээс ойролцоох мал нядалгааны газар руу чиглэн галт тэрэгний ачааны үхэр ангилж байх үед л тасалдсан гэдгийг мэдсэн. Энэ нь өөрөө хачирхалтай байсан, учир нь нядалгааны газрыг Казахстанд илүү ойрхон байрладаг фермүүд нийлүүлдэг байв.
1986 онд Чернобылийн атомын цахилгаан станц дэлбэрч, цацраг идэвхт бодисууд орчмын газруудыг хүн амьдрах боломжгүй болгосон. Украины хойд хэсэг, Беларусь, Оросын баруун хэсгийн өргөн уудам газар нутаг бохирдсон байна. Ирж буй вагонд цацраг идэвхт бодис их байна гэж сэжиглэж байсан Сергей энэ онолыг шалгах аргыг боловсруулжээ. Хүн амд дозиметр хэрэглэхийг хориглосон тул Сергей өөрийгөө төмөр замын буудал дээр хэд хэдэн цэргийн албан хаагчид бүртгүүлжээ. Хэд хэдэн удаа архи уусны дараа тэрээр нэгэн цэрэгт сэжигтэй вагонд цацрагийн хэмжээг хэмжихийг ятгаж чаджээ. Энэ түвшин хэвийн хэмжээнээс хэд дахин их байсан нь тогтоогдсон.
Үхэр маш их цацраг ялгаруулаад зогсохгүй түүний түвшин маш өндөр байсан тул станцын хажуугийн байранд байрлах SM-1800-ийн санах ойд санамсаргүй бит алдагдахад хүргэсэн.
ЗХУ-д хүнсний хомсдол үүсч, эрх баригчид Чернобылийн махыг бусад бүс нутгийн махтай холих шийдвэр гаргажээ. Энэ нь үнэ цэнэтэй нөөцийг алдагдуулахгүйгээр цацраг идэвхт байдлын ерөнхий түвшинг бууруулах боломжтой болсон. Үүнийг мэдсэн Сергей тэр даруй цагаачлах бичиг баримтыг бөглөв. Цацрагийн түвшин цаг хугацааны явцад буурах үед компьютерийн уналт өөрөө зогссон.
Хоолойгоор дамжин
Нэгэн цагт Movietech Solutions нь нягтлан бодох бүртгэл, тасалбар худалдаа, ерөнхий менежментэд зориулагдсан кино театруудад зориулсан программ хангамжийг бүтээжээ. Тэргүүлэгч програмын DOS хувилбар нь Хойд Америкийн жижиг, дунд хэмжээний кино театруудын сүлжээнүүдийн дунд нэлээд алдартай байсан. Тиймээс хамгийн сүүлийн үеийн мэдрэгчтэй дэлгэц, өөрөө үйлчилдэг ТҮЦ-үүдтэй, бүх төрлийн тайлагнах хэрэгслээр тоноглогдсон Windows 95 хувилбарыг зарлахад энэ нь маш хурдан алдартай болсон нь гайхах зүйл биш юм. Ихэнх тохиолдолд шинэчлэлт нь асуудалгүй явагддаг. Орон нутгийн мэдээллийн технологийн ажилтнууд шинэ тоног төхөөрөмж суурилуулж, өгөгдлийг шилжүүлж, бизнесээ үргэлжлүүлэв. Энэ нь үргэлжилээгүй үеийг эс тооцвол. Ийм зүйл болоход тус компани "Цэвэрлэгч" хочит Жеймсийг явуулна.
Хэдийгээр энэ хоч нь харгис төрлийг илтгэж байгаа ч цэвэрлэгч нь зүгээр л зааварлагч, суулгагч, бүх төрлийн арилжааны хосуудын нэгдэл юм. Жеймс үйлчлүүлэгчийн сайтад хэдэн өдөр зарцуулж, бүх бүрэлдэхүүн хэсгүүдийг нэгтгэж, дараа нь ажилтнуудад шинэ системийг хэрхэн ашиглахыг зааж, техник хангамжийн аливаа асуудлыг шийдэж, програм хангамжийг анхан шатанд нь туслахад нь туслах болно.
Тиймээс энэ их ачаалалтай үед Жеймс өглөө оффис дээрээ ирсэн бөгөөд түүнийг ширээ рүүгээ орохоос өмнө менежер түүнийг ердийнхөөс илүү кофеиноор дүүргэсэн угтсан нь гайхах зүйл биш юм.
"Чамайг Нова Скотиа мужийн Аннаполис руу аль болох хурдан очих хэрэгтэй гэж би айж байна." Тэдний систем бүхэлдээ доголдож, инженерүүдтэйгээ шөнөжин ажилласны дараа юу болсныг бид ойлгохгүй байна. Сүлжээ сервер дээр амжилтгүй болсон бололтой. Гэхдээ систем хэдэн минутын турш ажилласны дараа л.
-Тэд хуучин систем рүүгээ ороогүй юм уу? - Жеймс үнэхээр нухацтай хариулсан ч сэтгэлийнхээ хувьд гайхсандаа нүдээ томрууллаа.
- Яг: тэдний мэдээллийн технологийн мэргэжилтэн "тэргүүлэх чиглэлээ өөрчилсөн" бөгөөд хуучин серверээ орхихоор шийдсэн. Жеймс, тэд системийг зургаан сайт дээр суулгаж, дээд зэргийн тусламжийн төлбөрийг төлсөн бөгөөд тэдний бизнес одоо 1950-иад оных шиг явагдаж байна.
Жеймс бага зэрэг босоод:
-Тэр бол өөр хэрэг. За, эхэлцгээе.
Түүнийг Аннаполис хотод ирэхэд хамгийн түрүүнд хийсэн зүйл бол үйлчлүүлэгчийн асуудалтай тулгарсан анхны театрыг олох явдал байв. Онгоцны буудал дээр авсан газрын зураг дээр бүх зүйл хэвийн харагдаж байсан ч хүссэн хаягийн эргэн тойронд сэжигтэй харагдаж байв. Гетто биш, харин noir киног санагдуулдаг. Жеймс хотын замын захад машинаа зогсоож байтал биеэ үнэлэгч түүн рүү ойртов. Аннаполисын хэмжээг харгалзан үзвэл энэ нь бүхэл бүтэн хотод цорын ганц байсан байх магадлалтай. Түүний гадаад төрх нь том дэлгэцэн дээр мөнгөний төлөө секс хийхийг санал болгосон алдартай дүрийг санаанд шууд оруулсан. Үгүй ээ, Жулиа Робертсийн тухай биш, харин Жон Войтын тухай ["Шөнө дундын ковбой" киноны зүйрлэл - ойролцоогоор. эгнээ].
Биеэ үнэлэгчийг замд нь явуулсны дараа Жеймс кино театр руу явав. Ойролцоох газар нь сайжирсан ч унасан мэт сэтгэгдэл төрүүлэв. Жеймс хэтэрхий их санаа зовсонгүй. Тэр өмнө нь хөөрхийлөлтэй газруудаар явж байсан. Энэ бол хулгайч нар хүртэл түрийвчээ авчихаад "баярлалаа" гэж эелдэг ханддаг Канад байсан.
Кино театрын хажуугийн хаалга нь харанхуй гудамжинд байв. Жеймс хаалга руу алхаж, тогшив. Удалгүй шаржигнан бага зэрэг нээгдэв.
-Та цэвэрлэгч үү? - дотроос сөөнгө хоолой сонсогдов.
- Тийм ээ, энэ бол би... Би бүх зүйлийг засах гэж ирсэн.
Жеймс кино театрын үүдний танхим руу оров. Өөр сонголт байхгүй бололтой ажилтнууд зочдод цаасан тасалбар тарааж эхлэв. Энэ нь санхүүгийн тайлагналыг улам хүндрүүлэхээс гадна илүү сонирхолтой мэдээлэл өгөхөд хүргэсэн. Гэвч ажилтнууд Жеймсийг тайвширсан байдалтай угтан аваад шууд л серверийн өрөөнд аваачлаа.
Эхлээд харахад бүх зүйл сайхан байсан. Жеймс серверт нэвтэрч, ердийн сэжигтэй газруудыг шалгав. Асуудалгүй. Гэсэн хэдий ч маш болгоомжтойгоор Жеймс серверийг унтрааж, сүлжээний картыг сольж, системийг буцаав. Тэр даруй бүрэн хэмжээгээр ажиллаж эхлэв. Ажилтнууд дахин тасалбар зарж эхлэв.
Жеймс Марк руу утасдаж нөхцөл байдлын талаар мэдэгдэв. Жеймс гэнэтийн зүйл тохиолдсон эсэхийг харахыг хүсч магадгүй гэж төсөөлөхөд хэцүү биш юм. Тэр шатаар бууж, ажилчдаас юу болсныг асууж эхлэв. Систем ажиллахаа больсон нь ойлгомжтой. Тэд үүнийг унтрааж, асаасан, бүх зүйл ажилласан. Гэвч 10 минутын дараа систем унтарсан.
Яг энэ мөчид үүнтэй төстэй зүйл тохиолдов. Гэнэт тасалбарын систем алдаа гаргаж эхлэв. Ажилтнууд санаа алдаад цаасан тасалбарыг шүүрэн авч, Жеймс серверийн өрөө рүү яаравчлав. Серверийн хувьд бүх зүйл сайхан харагдаж байна.
Тэгтэл нэг ажилчин орж ирлээ.
- Систем дахин ажиллаж байна.
Жеймс юу ч хийгээгүй болохоор гайхаж байлаа. Бүр тодруулбал, системийг ажиллуулах ямар ч зүйл байхгүй. Тэр гараад утсаа аваад компанийнхаа тусламжийн утас руу залгав. Удалгүй нөгөө ажилтан серверийн өрөөнд оров.
-Систем унтарсан.
Жеймс сервер рүү харав. Дэлгэцэн дээр бүжиглэж буй олон өнгийн хэлбэрийн сонирхолтой бөгөөд танил загвар - эмх замбараагүй мушгирсан хоолойнууд. Бид бүгдээрээ энэ дэлгэц амраагчийг хэзээ нэгэн цагт харсан. Энэ нь үнэхээр сайхан дүрслэгдсэн бөгөөд жинхэнэ утгаараа ховсдож байна.
Жеймс товчлуур дарахад хээ алга болов. Тэр тасалбарын касс руу яаран очиж, замдаа өөрт нь буцаж ирсэн ажилтантай таарав.
- Систем дахин ажиллаж байна.
Хэрэв та сэтгэлгээний алгаа хийж чадвал Жеймс яг ийм зүйл хийсэн. Дэлгэц амраагч. Энэ нь OpenGL ашигладаг. Тиймээс үйл ажиллагааны явцад сервер процессорын бүх нөөцийг зарцуулдаг. Үүний үр дүнд сервер рүү хийсэн дуудлага бүр хугацаа дуусдаг.
Жеймс серверийн өрөөнд буцаж ирээд нэвтэрч, дэлгэц амраагчийг хоосон дэлгэцтэй сайхан хоолойгоор сольсон. Өөрөөр хэлбэл, процессорын нөөцийг 100% зарцуулдаг дэлгэц амрагчийн оронд би нөөцийг ашигладаггүй өөр нэгийг суулгасан. Дараа нь би таамаглаа шалгахын тулд 10 минут хүлээв.
Жэймс дараагийн кино театрт ирэхдээ дэлгэцийн амраагчаа унтраахаар 800 км ниссэнээ менежертээ яаж тайлбарлах вэ гэж бодож байв.
Сарны тодорхой үе шатанд осолдох
Үнэн түүх. Нэг өдөр сарны фазаас хамаарах програм хангамжийн алдаа гарч ирэв. MIT-ийн янз бүрийн хөтөлбөрүүдэд сарны жинхэнэ үе шаттай ойртохыг тооцоолохын тулд бага зэрэг ашигладаг байсан. GLS энэ горимыг LISP програм болгон бүтээж, файл бичихдээ бараг 80 тэмдэгтийн урттай цагийн тэмдэг бүхий мөр гаргадаг. Мессежийн эхний мөр хэт урт болж, дараагийн мөрөнд хүргэх нь маш ховор байсан. Тэгээд дараа нь программ энэ файлыг уншихад хараал идсэн. Эхний мөрийн урт нь яг огноо, цаг хугацаа, түүнчлэн цагийг хэвлэх үеийн үе шатны тодорхойлолтын уртаас хамаарна. Өөрөөр хэлбэл, алдаа нь сарны үе шатаас шууд хамааралтай байсан!
Анхны цаасан хэвлэл (Стиле-1983) нь тайлбарласан алдаанд хүргэсэн ийм мөрийн жишээг агуулж байсан боловч бичээч үүнийг "засасан". Үүнээс хойш үүнийг "сарны фазын алдаа" гэж тодорхойлсон.
Гэсэн хэдий ч таамаглалд болгоомжтой хандах хэрэгтэй. Хэдэн жилийн өмнө CERN-ийн (Европын Цөмийн Судалгааны Төв) инженерүүд Том электрон-позитрон коллайдер дээр хийсэн туршилтын явцад алдаа гарсан. Компьютерууд үр дүнг нь эрдэмтдэд үзүүлэхээс өмнө энэ төхөөрөмжөөр үүсгэгдсэн асар их хэмжээний өгөгдлийг идэвхтэй боловсруулдаг тул олон хүн уг программ хангамжийг сарны үе шатанд ямар нэгэн байдлаар мэдрэмтгий гэж таамаглаж байсан. Цөхрөнгөө барсан хэдэн инженер үнэний ёроолд хүрсэн. Сарыг дайран өнгөрөх үед дэлхийн хэв гажилтын улмаас 27 км урт цагирагийн геометрийн хэлбэр бага зэрэг өөрчлөгдсөний улмаас алдаа гарсан! Энэхүү түүх нь физикийн ардын аман зохиолд "Бөөмийн физикийн Ньютоны өшөө авалт" нэрээр орж ирсэн бөгөөд физикийн хамгийн энгийн бөгөөд эртний хуулиуд болон шинжлэх ухааны дэвшилтэт ойлголтуудын хоорондын уялдаа холбоог харуулсан жишээ юм.
Жорлонг угаах нь галт тэрэгний хөдөлгөөнийг зогсооно
Миний сонсож байсан техник хангамжийн хамгийн сайн алдаа бол Францад хурдны галт тэргэнд явж байсан явдал юм. Алдаа нь галт тэргийг яаралтай тоормослоход хүргэсэн боловч зөвхөн онгоцонд зорчигч байсан тохиолдолд л. Ийм тохиолдол бүрт галт тэргийг үйлчилгээнээс гаргаж, шалгасан боловч юу ч олдсонгүй. Дараа нь түүнийг шугам руу буцаасан, тэр даруй зогссон.
Нэг шалгалтын үеэр галт тэргэнд явж байсан инженер бие засах газар руу орсон байна. Тэр удалгүй угаасан, BOOM! Яаралтай зогсолт.
Инженер жолоочтой холбогдож:
- Та тоормослохын өмнөхөн юу хийж байсан бэ?
-За би буухдаа удааширсан...
Энэ нь хачирхалтай байсан, учир нь галт тэрэг хэвийн ажиллаж байх үед буухдаа хэдэн арван удаа удааширдаг. Галт тэрэг хөдөлж, дараагийн буулт дээр жолооч анхааруулав:
- Би удаашрах гэж байна.
Юу ч болоогүй.
- Хамгийн сүүлд тоормослохдоо юу хийсэн бэ? гэж жолооч асуув.
-За... Би жорлонд байсан...
- За тэгвэл бие засах газар ороод биднийг дахин буухад хийсэн зүйлээ хий!
Инженер бие засах газар руу явж, жолооч "Би удааширч байна" гэж анхааруулахад тэр усыг зайлуулжээ. Мэдээж галт тэрэг тэр дороо зогсов.
Одоо тэд асуудлыг дахин гаргаж болох бөгөөд шалтгааныг олох шаардлагатай болсон.
Хоёр минутын дараа тэд хөдөлгүүрийн тоормосны алсын удирдлагатай кабель (галт тэрэгний төгсгөлд нэг хөдөлгүүртэй) цахилгааны кабинетийн хананаас салж, жорлонгийн залгуурыг удирддаг реле дээр хэвтэж байгааг анзаарсан ... Реле үед асаалттай байсан бөгөөд энэ нь тоормосны кабельд хөндлөнгийн оролцоо үүсгэж, системийн алдаанаас хамгаалах хамгаалалт нь яаралтай тоормосыг багтаасан болно.
FORTRAN-ыг үзэн яддаг гарц
Хэдэн сарын өмнө бид эх газрын сүлжээний холболтууд [энэ нь Хавайд байсан] маш удаан болж байгааг анзаарсан. Энэ нь 10-15 минут үргэлжилж, дараа нь гэнэт дахин тохиолдож болно. Хэсэг хугацааны дараа манай хамт олон эх газрын сүлжээний холболтыг надад гомдоллосон ерөнхийдөө Ажиллахгүй байна. Түүнд эх газрын машин руу хуулах шаардлагатай зарим FORTRAN код байсан ч "FTP байршуулалтыг дуусгахад сүлжээ хангалттай удаан хүлээгээгүй" учир үүнийг хийж чадаагүй юм.
Тиймээ, хамтран ажиллагсад нь эх газрын машин руу FORTRAN дахь эх кодтой файлыг FTP гэж оролдох үед сүлжээний доголдол гарсан нь тогтоогдсон. Бид файлыг архивлах гэж оролдсон: дараа нь үүнийг жигд хуулсан (гэхдээ зорилтот машин задлагчгүй байсан тул асуудал шийдэгдээгүй). Эцэст нь бид FORTRAN кодыг маш жижиг хэсгүүдэд хувааж, нэг нэгээр нь илгээсэн. Ихэнх хэлтэрхийнүүд ямар ч асуудалгүй хуулбарлагдсан боловч цөөн хэдэн хэсэг нь дамжаагүй эсвэл дараа нь дамжсан олон тооны оролдлого.
Асуудалтай хэсгүүдийг судалж үзэхэд бид тэдгээрт нийтлэг зүйл байдгийг олж мэдсэн: тэдгээр нь бүгд том С-ээс бүрдсэн мөрүүдээр эхэлж, төгссөн тайлбар блокуудыг агуулж байсан (хамтран ажиллагсад FORTRAN хэл дээр тайлбар хийхийг илүүд үздэг байсан). Бид эх газрын сүлжээний мэргэжилтнүүдтэй цахим шуудан илгээж, тусламж хүссэн. Мэдээжийн хэрэг, тэд FTP-ээр дамжуулах боломжгүй бидний файлуудын дээжийг харахыг хүссэн боловч бидний захидал тэдэнд хүрээгүй. Эцэст нь бид энгийн зүйлийг олж мэдэв дүрслэхшилжүүлэх боломжгүй файлууд ямар харагддаг. Энэ ажилласан :) [Би энд асуудалтай FORTRAN-ын нэг жишээг нэмж хэлэх үү? Энэ нь үнэ цэнэтэй биш байх!]
Эцэст нь бид үүнийг ойлгож чадсан. Саяхан манай оюутны хотхоны хэсэг болон эх газрын сүлжээний хооронд шинэ гарц суурилуулсан. Том үсгийн С-ийн давтагдсан битүүдийг агуулсан пакетуудыг дамжуулахад маш их бэрхшээлтэй тулгарсан! Эдгээр пакетуудын хэдхэн нь л гарцын бүх нөөцийг авч, бусад ихэнх пакетуудыг нэвтрүүлэхээс сэргийлж чадна. Бид гарц үйлдвэрлэгчид гомдол гаргасан ... тэд хариулав: "Өө, тийм ээ, та дахин дахин C алдаатай тулгарлаа! Бид түүний талаар аль хэдийн мэддэг болсон." Эцэст нь бид өөр үйлдвэрлэгчээс шинэ гарц худалдаж авснаар асуудлыг шийдсэн (өмнөх нь FORTRAN программыг шилжүүлэх боломжгүй байх нь зарим хүмүүсийн хувьд давуу тал байж магадгүй юм!).
Хэцүү цаг үе
Хэдэн жилийн өмнө 40-р шатны эмнэлзүйн туршилтын зардлыг бууруулахын тулд Perl-д ETL системийг бий болгохоор ажиллаж байхдаа би 000 огноо боловсруулах шаардлагатай болсон. Тэдний хоёр нь шалгалтад тэнцээгүй. Энэ нь надад тийм ч их санаа зовдоггүй байсан, учир нь эдгээр огноог үйлчлүүлэгчийн өгсөн өгөгдлөөс авсан байсан нь ихэвчлэн гайхшруулдаг. Гэтэл анхны мэдээллийг нь шалгахад 1 оны 2011 сарын 1, 2007 оны 30 сарын XNUMX гэсэн огноонууд байсан. Сая бичсэн программ дээр алдаа байгаа гэж бодсон чинь XNUMX жил болчихсон байна. хуучин. Програм хангамжийн экосистемийг мэдэхгүй хүмүүст энэ нь нууцлаг сонсогдож магадгүй юм. Удаан хугацааны турш өөр компани мөнгө олох шийдвэр гаргаснаас болж манай үйлчлүүлэгч нэг компанийн санамсаргүй байдлаар, нөгөө нь зориудаар оруулсан алдааг засч залруулахын тулд надад мөнгө төлсөн. Миний юу яриад байгааг ойлгохын тулд би алдаа болсон функцийг нэмсэн компани болон миний зассан нууцлаг алдааг бий болгоход нөлөөлсөн бусад сонирхолтой үйл явдлын талаар ярих хэрэгтэй байна.
Эрт дээр үед Apple-ийн компьютерууд заримдаа 1 оны 1904-р сарын 1-ний өдрийг аяндаа шинэчилдэг байв. Шалтгаан нь энгийн байсан: огноо, цагийг хянахын тулд батарейгаар ажилладаг "системийн цаг" ашигласан. Батерей дуусахад юу болсон бэ? Компьютерууд эрин үе эхэлснээс хойш хэдэн секундын тоогоор огноог хянаж эхлэв. Эрин үе гэж бид лавлах анхны огноог хэлж байсан бөгөөд Macintoshes-ийн хувьд энэ нь 1904 оны XNUMX-р сарын XNUMX-ний өдөр байсан. Мөн батерей дууссаны дараа одоогийн огноог заасан огноо руу шилжүүлсэн. Гэхдээ яагаад ийм зүйл болсон бэ?
Өмнө нь Apple анхны огнооноос хойшхи секундын тоог хадгалахын тулд 32 бит ашигладаг байсан. Нэг бит нь 1 эсвэл 0 гэсэн хоёр утгын аль нэгийг хадгалах боломжтой. Хоёр бит нь 00, 01, 10, 11 гэсэн дөрвөн утгын аль нэгийг хадгалах боломжтой. Гурван бит - найман утгын нэг нь: 000, 001, 010, 011, 100 , 101, 110, 111 гэх мэт. Мөн 32 нь 232 утгын аль нэгийг буюу 4 секундийг хадгалах боломжтой. Apple-ийн огнооны хувьд энэ нь ойролцоогоор 294 жилтэй тэнцэж байгаа тул хуучин Mac-ууд 967 оноос хойшхи хугацааг зохицуулах боломжгүй юм. Хэрэв системийн батарей унтарвал эрин үе эхэлснээс хойш огноог 296 секунд болгож шинэчилдэг бөгөөд та компьютераа асаах бүртээ (эсвэл шинэ батерей худалдаж авах хүртэл) огноог гараар тохируулах шаардлагатай болдог.
Гэсэн хэдий ч Apple-ийн огноог эрин үеэс хойш секундээр хадгалахаар шийдсэн нь бид эрин үеэс өмнөх огноог зохицуулж чадахгүй гэсэн үг бөгөөд энэ нь бидний харж байгаачлан өргөн хүрээтэй үр дагавартай байсан. Apple компани алдаа биш функцийг нэвтрүүлсэн. Бусад зүйлсийн дотор энэ нь Macintosh үйлдлийн систем нь "мянганы алдаа"-аас дархлаатай гэсэн үг юм (хязгаарлалтаас зайлсхийхийн тулд өөрийн огнооны системтэй олон Mac програмуудын талаар хэлж болохгүй).
Үргэлжлүүл. Бид IBM-ийн "алуурч програм" болох Lotus 1-2-3-ыг ашигласан бөгөөд энэ нь PC-ийн хувьсгалыг эхлүүлэхэд тусалсан боловч Apple-ийн компьютерууд VisiCalc-тэй байсан нь персонал компьютерийг амжилтанд хүргэсэн. Шударгаар хэлэхэд, хэрэв 1-2-3 гарч ирээгүй бол PC-үүд бараг хөөрөхгүй, персонал компьютерийн түүх тэс өөрөөр хөгжиж болох байсан. Бадамлянхуа 1-2-3 1900 оныг өндөр жил гэж буруу авч үзсэн. Майкрософт компани Multiplan хэмээх анхны хүснэгтээ гаргахдаа зах зээлийн багахан хувийг эзэлжээ. Мөн тэд Excel төслийг эхлүүлэхдээ Лотус 1-2-3-аас мөр, баганын нэршлийн схемийг хуулж аваад зогсохгүй 1900 оныг үсрэлтийн жил гэж зориудаар авч үзэх замаар алдааны нийцтэй байдлыг хангахаар шийджээ. Энэ асуудал өнөөдөр ч байсаар байна. Өөрөөр хэлбэл, 1-2-3-т энэ нь алдаа байсан боловч Excel-д энэ нь 1-2-3 хэрэглэгчид алдаатай байсан ч гэсэн өгөгдлийг өөрчлөхгүйгээр хүснэгтээ Excel-д импортлох боломжийг баталгаажуулсан ухамсартай шийдвэр байв.
Гэхдээ өөр асуудал байсан. Эхлээд Microsoft 1 оны 1904-р сарын 1-ээс өмнөх огноог хүлээн зөвшөөрдөггүй байсан Excel-ийг Macintosh-д зориулж гаргасан. Excel-д 1900 оны XNUMX-р сарын XNUMX-ийг эриний эхлэл гэж үздэг. Тиймээс хөгжүүлэгчид өөрчлөлт хийсэн бөгөөд ингэснээр программ нь тухайн эрин үеийн төрлийг таньж, хүссэн эрин үеийнхээ дагуу өгөгдлийг өөртөө хадгалдаг болсон. Майкрософт энэ талаар тайлбарласан нийтлэл хүртэл бичсэн. Мөн энэ шийдвэр миний алдаа гаргахад хүргэсэн.
Миний ETL систем Windows дээр бүтээгдсэн боловч Mac дээр ч үүсгэж болох Excel хүснэгтүүдийг үйлчлүүлэгчдээс хүлээн авсан. Тиймээс хүснэгтийн эриний эхлэл нь 1 оны 1900-р сарын 1 эсвэл 1904 оны XNUMX-р сарын XNUMX байж болно. Яаж мэдэх вэ? Excel файлын формат нь шаардлагатай мэдээллийг харуулдаг боловч миний ашигласан задлан шинжлэгч үүнийг харуулаагүй (одоо харуулж байна) бөгөөд та тодорхой хүснэгтийн эрин үеийг мэддэг гэж үзсэн. Би Excel-ийн хоёртын форматыг ойлгоход илүү их цаг зарцуулж, задлагч зохиогч руу нөхөөс илгээж болох байсан ч надад үйлчлүүлэгчийн төлөө хийх зүйл их байсан тул би эрин үеийг тодорхойлох эвристикийг хурдан бичлээ. Тэр энгийн байсан.
Excel-д 5 оны 1998-р сарын 07-ны огноог "05-98-5" (ашиггүй Америкийн систем), "98-р сарын 5, 1998", "5 оны 98-р сарын 8601", "35981-1900-34519" форматаар илэрхийлж болно. өөр формат. өөр нэг хэрэггүй формат (хачирхалтай нь, миний Excel-ийн хувилбарын санал болгож байгаагүй форматуудын нэг нь ISO 1904 байсан). Гэсэн хэдий ч хүснэгтэд форматлагдаагүй огноог 4 оны эрин үед "1904" эсвэл XNUMX оны эрин үед "XNUMX" гэж хадгалсан (тоонууд нь эрин үеэс хойшхи өдрүүдийн тоог илэрхийлдэг). Би зүгээр л форматлагдсан огнооноос оныг гаргаж авахын тулд энгийн задлан шинжлэгч ашигласан, дараа нь форматлагдаагүй огнооноос оныг гаргаж авахын тулд Excel задлагчийг ашигласан. Хэрэв хоёр утга нь XNUMX жилээр ялгаатай байсан бол би XNUMX оны эрин үеийн системийг ашиглаж байгаагаа мэдэж байсан.
Яагаад би зүгээр л форматлагдсан огноог ашиглаагүй юм бэ? Учир нь 5 оны 1998-р сарын 98-ны өдрийг "XNUMX-р сар, XNUMX" гэж форматлах боломжтой. Бид маш олон компаниудаас хүснэгтүүдийг хүлээн авсан бөгөөд тэдгээрийг маш олон янзаар бүтээсэн тул огноог тодорхойлох нь биднээс (энэ тохиолдолд би) хамаарна. Нэмж дурдахад, хэрэв Excel үүнийг зөв хийсэн бол бид ч мөн адил байх ёстой!
Яг тэр үед би 39082-той таарсан. Бадамлянхуа 1-2-3 нь 1900 оныг үсрэлтийн жил гэж үзсэн бөгөөд энэ нь Excel-д үнэнчээр давтагдсан гэдгийг сануулъя. Энэ нь 1900 оныг нэг өдөр нэмсэн тул огноог тооцоолох олон функцууд яг тэр өдөр буруу байж магадгүй юм. Өөрөөр хэлбэл, 39082 нь 1 оны 2011-р сарын 31 (Mac дээр) эсвэл 2006 оны 2011-р сарын 1900 (Windows дээр) байж болно. Хэрэв миний "жил задлагч" форматлагдсан утгаас 2006 оныг гаргаж авсан бол бүх зүйл хэвийн байна. Гэхдээ Excel задлагч нь ямар эрин үеийг ашиглаж байгааг мэдэхгүй тул анхдагчаар epoch-5 болгож, XNUMX оныг буцаана. Миний өргөдөл XNUMX жилийн зөрүү байгааг хараад алдаа гэж үзээд бүртгэлд оруулаад форматлагдаагүй утгыг буцаасан.
Үүнийг тойрон гарахын тулд би үүнийг бичсэн (псевдокод):
diff = formatted_year - parsed_year
if 0 == diff
assume 1900 date system
if 4 == diff
assume 1904 date system
if 5 == diff and month is December and day is 31
assume 1904 date system
Тэгээд бүх 40 огноог зөв задлан шинжилсэн.
Том хэвлэх ажлын дунд
1980-аад оны эхээр аав маань өндөр хурдны соронзон хальсны тэжээлд зориулсан соронзон хальсны хөтчүүд болон пневматик системийг бүтээдэг одоо татан буугдсан "Storage Technology" хэлтэст ажилладаг байв.
Тэд хөтчүүдийг дахин зохион бүтээсэн бөгөөд ингэснээр тэдгээр нь долоон "В" дисктэй холбогдсон нэг төв "А" хөтөчтэй байх ба "А" дискийг удирддаг RAM дахь жижиг үйлдлийн систем нь бүх "B" хөтчүүдэд унших, бичих үйлдлийг шилжүүлэх боломжтой болсон.
"А" дискийг эхлүүлэх бүрт үйлдлийн системийг санах ойд ачаалахын тулд "А"-д холбогдсон захын дискэнд уян диск оруулах шаардлагатай болдог. Энэ нь маш энгийн байсан: тооцоолох хүчийг 8 битийн микроконтроллероор хангадаг байв.
Ийм тоног төхөөрөмжийн зорилтот үзэгчид нь маш олон тооны хаягийн шошго эсвэл банкны хуулга хэвлэх шаардлагатай банк, жижиглэн худалдааны сүлжээ гэх мэт маш том мэдээллийн агуулахтай компаниуд байв.
Нэг үйлчлүүлэгч асуудалтай тулгарсан. Хэвлэх ажлын дундуур нэг "А" хөтөч ажиллахаа больж, ажил бүхэлдээ зогсонги байдалд ороход хүргэдэг. Драйвын ажиллагааг сэргээхийн тулд ажилтнууд бүх зүйлийг дахин ачаалах шаардлагатай болсон. Хэрэв энэ нь зургаан цагийн ажлын дундуур болсон бол компьютерын асар их цаг хугацаа алдаж, бүхэл бүтэн үйл ажиллагааны хуваарь тасалдсан.
Storage Technologies-ээс техникчдийг илгээсэн. Гэвч тэд хамгийн сайн хүчин чармайлтыг үл харгалзан туршилтын нөхцөлд алдааг дахин гаргаж чадаагүй: энэ нь том хэвлэх ажлын дундуур гарсан мэт санагдсан. Асуудал нь техник хангамжид байсангүй, тэд чадах бүхнээ сольсон: RAM, микроконтроллер, уян диск, соронзон хальсны хөтчийн төсөөлж болох хэсэг бүр - асуудал үргэлжилсээр байв.
Дараа нь техникийн ажилтнууд төв байр руу утасдаж, Шинжээчийг дуудсан.
Мэргэжилтэн сандал, аяга кофе аваад компьютерийн өрөөнд суугаад - тэр үед компьютерт зориулагдсан өрөөнүүд байсан - ажилтнууд том хэвлэх ажилд оочерлож байхыг харав. Мэргэжилтэн бүтэлгүйтэл гарахыг хүлээж байсан - тэгсэн. Бүгд Эксперт рүү харсан ч яагаад ийм зүйл болсныг тэр мэдэхгүй. Тиймээс тэр ажлыг дахин дараалалд оруулахыг тушааснаар бүх ажилтан, техникийн ажилтнууд ажилдаа буцаж ирэв.
Шинжээч дахин сандал дээр суугаад бүтэлгүйтлийг хүлээж эхлэв. Зургаан цаг өнгөрч, бүтэлгүйтсэн. Бүх зүйл хүмүүсээр дүүрсэн өрөөнд болсныг эс тооцвол Мэргэжилтэнд дахин ямар ч санаа байсангүй. Тэрээр номлолыг дахин эхлүүлэхийг тушааж, буцаж суугаад хүлээв.
Гурав дахь бүтэлгүйтлээр Мэргэжилтэн нэг зүйлийг анзаарав. Ажилтнууд гадаад хөтөч дээрх соронзон хальснуудыг солих үед алдаа гарсан. Түүгээр ч барахгүй ажилчдын нэг нь шалан дээрх тодорхой хавтангаар дамжин өнгөрөхөд л бүтэлгүйтэл гарсан.
Өргөгдсөн шалыг 6-8 инч өндөрт тавьсан хөнгөн цагаан хавтангаар хийсэн. Хэн нэгэн чухал кабель дээр санамсаргүй гишгэхээс сэргийлж, өндөр шалан доогуур компьютерийн олон тооны утаснууд урсан байв. Өргөгдсөн шалан доор хог хаягдлыг оруулахгүйн тулд хавтангуудыг маш нягт тавьсан.
Мэргэжилтэн нэг хавтан нь гажигтай байгааг ойлгосон. Ажилтан түүний буланд гишгэх үед хавтангийн ирмэг нь зэргэлдээх хавтангуудыг үрж байв. Хавтанцарыг холбосон хуванцар эд ангиудыг мөн үрж, улмаар статик бичил цэнэг үүсгэж, радио давтамжийн хөндлөнгийн оролцоо үүсгэсэн.
Өнөөдөр RAM нь радио давтамжийн хөндлөнгийн оролцооноос илүү сайн хамгаалагдсан. Гэвч тэр жилүүдэд тийм байгаагүй. Энэхүү хөндлөнгийн оролцоо нь санах ой, түүнтэй хамт үйлдлийн системийн ажиллагааг тасалдуулж байгааг шинжээч ойлгосон. Тэрээр дэмжлэг үзүүлэх үйлчилгээг дуудаж, шинэ хавтан захиалж, өөрөө суулгаж, асуудал арилсан.
Өндөр түрлэг байна!
Үйл явдал Портсмут дахь оффисын дөрөв, тав дахь давхарт байрлах серверийн өрөөнд (миний бодлоор), усан онгоцны зогсоолын хэсэгт болсон.
Нэг өдөр үндсэн мэдээллийн сантай Unix сервер гацсан. Тэд түүнийг дахин ачаалсан боловч тэр баяртайгаар дахин дахин унасаар байв. Бид туслах үйлчилгээний хэн нэгэн рүү залгахаар шийдсэн.
Туслах залуу... Би түүний нэрийг Марк байсан гэж бодож байна, гэхдээ энэ нь хамаагүй... Би түүнийг танихгүй гэж бодож байна. Энэ хамаагүй, үнэхээр. Марктай хамт байцгаая, за юу? Агуу их.
Ингээд хэдхэн цагийн дараа Марк ирээд (Лидсээс Портсмут хүртэл холгүй байна шүү дээ) серверийг асаахад бүх зүйл асуудалгүй болсон. Ердийн хараал идсэн дэмжлэг, үйлчлүүлэгч үүнд маш их бухимддаг. Марк бүртгэлийн файлуудыг гүйлгэн харахад ямар ч таагүй зүйл олдсонгүй. Ингээд Марк буцаад галт тэргэнд суугаад (эсвэл тэр ямар ч тээврийн хэрэгслээр ирсэн байлаа. Миний мэдэхийн хувьд энэ нь доголон үхэр байж болох юм... ямар ч байсан хамаагүй ээ, за юу?) дэмий үрээд Лидс рүү буцав. өдөр.
Тэр орой сервер дахин гацсан. Түүх нь адилхан ... сервер босдоггүй. Марк алсаас туслахыг оролдсон боловч үйлчлүүлэгч серверийг эхлүүлж чадахгүй байна.
Өөр галт тэрэг, автобус, нимбэгний шар эсвэл өөр ямар нэгэн новш, Марк Портсмут руу буцаж ирэв. Хараач, сервер ямар ч асуудалгүйгээр ачаалж байна! Гайхамшиг. Марк үйлдлийн систем эсвэл программ хангамжийн хувьд бүх зүйл хэвийн байгаа эсэхийг шалгахын тулд хэдэн цаг зарцуулж, Лидс рүү явав.
Өдрийн дундуур сервер гацаж байна (тайван байгаарай!). Энэ удаад серверийг солихын тулд техник хангамжийн туслах хүмүүсийг авчрах нь зүйтэй юм шиг санагдаж байна. Гэхдээ үгүй, 10 орчим цагийн дараа энэ нь бас унадаг.
Нөхцөл байдал хэд хоногийн турш давтагдсан. Сервер ажиллаж, 10 орчим цагийн дараа гацаж, дараагийн 2 цагт асахгүй. Тэд хөргөлт, санах ойн алдагдал, бүгдийг шалгасан боловч юу ч олсонгүй. Дараа нь сүйрэлүүд зогссон.
Долоо хоног санаа зоволтгүй өнгөрлөө... бүгд аз жаргалтай байлаа. Бүх зүйл дахин эхлэх хүртэл баяртай байна. Зураг нь адилхан. 10 цаг ажил, 2-3 цаг завсарлага...
Тэгээд хэн нэгэн (энэ хүн IT-тэй ямар ч холбоогүй гэж надад хэлсэн байх гэж бодож байна) хэлэв.
"Энэ бол далайн түрлэг!"
Энэхүү дуудлагыг хоосон харцаар харж, хэн нэгний гар хамгаалалтын дуудлагын товчлуур дээр эргэлзсэн байх.
"Энэ нь урсгалтай ажиллахаа больдог."
Кофе ууж суух зуураа "Түрлэгтийн жилийн дэвтэр"-ийг уншдаггүй IT-ийн тусламжийн ажилтнуудад энэ нь огт харийн ойлголт мэт санагдана. Энэ нь далайн түрлэгтэй ямар нэгэн байдлаар холбоотой байж болохгүй, учир нь сервер долоо хоног доголдолгүй ажилласан гэж тэд тайлбарлав.
"Өнгөрсөн долоо хоногт усны урсгал бага байсан ч энэ долоо хоногт өндөр байна."
Дарвуулт онгоцны лицензгүй хүмүүст зориулсан бяцхан нэр томъёо. Түрлэг нь сарны мөчлөгөөс хамаардаг. Мөн дэлхий эргэлдэж байх үед 12,5 цаг тутамд нар, сарны таталцлын нөлөөгөөр далайн түрлэг үүсдэг. 12,5 цагийн мөчлөгийн эхэнд их хэмжээний түрлэг, мөчлөгийн дунд үе нь уналт, төгсгөлд нь дахин ихэсдэг. Гэвч сарны тойрог зам өөрчлөгдөхийн хэрээр бага, өндөр түрлэг хоёрын ялгаа өөрчлөгддөг. Сар нь Нар, Дэлхий хоёрын хооронд эсвэл дэлхийн эсрэг талд (бүтэн сар эсвэл саргүй) байх үед бид Syzygyn түрлэгийг авдаг - хамгийн өндөр түрлэг ба хамгийн доод урсгал. Хагас саран дээр бид квадрат түрлэгийг авдаг - хамгийн бага түрлэг. Хоёр туйлын ялгаа ихээхэн буурдаг. Сарны мөчлөг 28 хоног үргэлжилнэ: syzygian - quadrature - syzygian - quadrature.
Техникчдэд далайн түрлэгийн мөн чанарыг тайлбарлахад тэд тэр даруй цагдаа дуудах хэрэгтэй гэж бодсон. Бас нэлээд логиктой. Гэхдээ тэр залуугийн зөв байсан нь харагдаж байна. Хоёр долоо хоногийн өмнө устгагч оффисын ойролцоо бэхлэгдсэн байв. Далайн түрлэг тодорхой өндөрт өргөх болгонд хөлөг онгоцны радарын пост серверийн өрөөний шалны түвшинд хүрч байв. Мөн радар (эсвэл электрон байлдааны хэрэгсэл эсвэл бусад цэргийн тоглоом) нь компьютерт эмх замбараагүй байдал үүсгэсэн.
Пуужингийн нислэгийн даалгавар
Надад том хэмжээний (400 мянга орчим шугам) пуужин хөөргөх удирдлага, хяналтын системийг үйлдлийн систем, хөрвүүлэгч, хэлний шинэ хувилбарт шилжүүлэх даалгавар өгсөн. Нарийвчлан хэлэхэд, Solaris 2.5.1-ээс Solaris 7 хүртэл, мөн Ada 83 дээр бичигдсэн Verdix Ada Development System (VADS) -аас Ada 95 дээр бичигдсэн Rational Apex Ada систем хүртэл. VADS-ийг Rational худалдаж авсан бөгөөд түүний бүтээгдэхүүн нь хуучирсан хэдий ч Rational нь Apex хөрвүүлэгч рүү шилжих шилжилтийг хөнгөвчлөхийн тулд VADS тусгай багцуудын нийцтэй хувилбаруудыг хэрэгжүүлэхийг оролдсон.
Гурван хүн надад кодыг цэвэрхэн эмхэтгэхэд тусалсан. Хоёр долоо хоног зарцуулсан. Тэгээд системийг ажиллуулахын тулд бие даан ажилласан. Товчхондоо, энэ нь миний тулгарч байсан програм хангамжийн системийн хамгийн муу архитектур, хэрэгжилт байсан тул портыг дуусгахад дахин хоёр сар зарцуулсан. Дараа нь системийг туршилтанд оруулсан бөгөөд энэ нь хэдэн сар үргэлжилсэн. Туршилтын явцад олдсон алдаануудыг би нэн даруй зассан боловч тэдний тоо маш хурдан буурсан (эх код нь үйлдвэрлэлийн систем байсан тул функц нь нэлээд найдвартай ажилласан, би шинэ хөрвүүлэгчид дасан зохицох явцад гарсан алдаануудыг арилгах хэрэгтэй болсон). Эцэст нь бүх зүйл хэвийн болж байхад намайг өөр төсөл рүү шилжүүлсэн.
Мөн Талархлын баярын өмнөх баасан гарагт утас дуугарав.
Пуужин хөөргөх туршилтыг гурван долоо хоногийн дараа хийх ёстой байсан бөгөөд тооллогын лабораторийн туршилтын үеэр тушаалын дарааллыг хаажээ. Бодит амьдрал дээр энэ нь туршилтыг зогсоож, хөдөлгүүрийг ажиллуулснаас хойш хэдхэн секундын дотор түгжрэл үүссэн тохиолдолд туслах системд хэд хэдэн эргэлт буцалтгүй үйлдлүүд гарч ирэх бөгөөд энэ нь пуужингийн урт бөгөөд өндөр өртөгтэй бэлэн байдлыг шаарддаг. Энэ нь эхлэхгүй байсан ч олон хүн цаг хугацаа, маш их мөнгө алдсанд маш их бухимдах байсан. Батлан хамгаалах яам мөнгийг бодлогогүй зарцуулдаг гэж хэнд ч битгий хэлээрэй—төсвийг нэгдүгээрт тавьдаггүй, дараа нь хуваарь гаргадаггүй гэрээ байгуулдаг менежертэй би хэзээ ч уулзаж байгаагүй.
Өмнөх саруудад энэ тооллогын сорилтыг олон янзын хувилбараар хэдэн зуун удаа хийж байсан бөгөөд цөөн хэдэн алдаа гарсан. Тиймээс ийм зүйл тохиолдох магадлал маш бага байсан ч үр дагавар нь маш чухал байсан. Эдгээр хүчин зүйлийг хоёуланг нь үржүүлбэл, энэ мэдээ миний болон олон арван инженер, менежерүүдийн хувьд сүйрсэн амралтын долоо хоногийг урьдчилан таамаглаж байсныг та ойлгох болно.
Тэгээд системийг зөөвөрлөсөн хүний хувьд надад анхаарал хандуулсан.
Аюулгүй байдлын хувьд чухал ач холбогдолтой ихэнх системүүдийн нэгэн адил олон параметрүүдийг бүртгэдэг байсан тул систем эвдрэхээс өмнө гүйцэтгэсэн хэдэн мөр кодыг тодорхойлоход хялбар байсан. Мэдээжийн хэрэг, тэдний хувьд ер бусын зүйл огт байсангүй; ижил илэрхийлэл нь нэг гүйлтийн үеэр хэдэн мянган удаа амжилттай хэрэгжсэн.
Бид Apex-ийн хүмүүсийг Rational руу дуудсан, учир нь тэд хөрвүүлэгчийг боловсруулсан хүмүүс байсан бөгөөд тэдний боловсруулсан зарим горимыг сэжигтэй кодоор дуудсан. Тэд (мөн бусад бүх хүмүүс) үндэсний хэмжээний чухал асуудлын үндсийг олох шаардлагатай болсонд сэтгэгдэл төрүүлсэн.
Сэтгүүлд сонирхолтой зүйл байхгүй тул бид орон нутгийн лабораторид асуудлыг дахин гаргахаар шийдсэн. Энэ үйл явдал 1000 гүйлт тутамд нэг удаа болдог тул энэ нь тийм ч амар ажил биш байв. Сэжигтэй шалтгаануудын нэг нь худалдагчийн боловсруулсан мутекс функц руу залгасан (VADS шилжих багцын нэг хэсэг) юм. Unlock түгжээг тайлахад хүргэсэнгүй. Функцийг дуудсан боловсруулах утас нь зүрхний цохилтын мессежийг боловсруулсан бөгөөд энэ нь секунд тутамд ирдэг. Бид давтамжийг 10 Гц, өөрөөр хэлбэл секундэд 10 удаа өсгөж, ажиллаж эхлэв. Нэг цагийн дараа систем өөрөө түгжигдсэн. Бүртгэлд бид бүртгэгдсэн мессежүүдийн дараалал нь амжилтгүй болсон туршилтын үеийнхтэй ижил байгааг харсан. Бид дахин хэд хэдэн гүйлт хийсэн, систем эхэлснээс хойш 45-90 минутын дараа байнга хаагдсан бөгөөд бүртгэх бүрт ижил маршрутыг оруулсан. Техникийн хувьд бид өөр өөр код ажиллуулж байсан ч - мессежийн давтамж өөр байсан - системийн үйл ажиллагаа ижил байсан тул энэ ачааллын хувилбар нь ижил асуудал үүсгэж байгаа гэдэгт бид итгэлтэй байсан.
Одоо бид илэрхийллийн дарааллаар яг хаана хаалт үүссэнийг олж мэдэх хэрэгтэй болсон.
Системийн энэхүү хэрэгжилт нь Ada даалгаврын системийг ашигласан бөгөөд үүнийг маш муу ашигласан. Даалгаварууд нь Ада дахь өндөр түвшний нэгэн зэрэг гүйцэтгэх боломжтой бүтэц бөгөөд гүйцэтгэх хэлхээтэй адил зүйл бөгөөд зөвхөн хэлэнд суулгагдсан байдаг. Хоёр даалгавар харилцах шаардлагатай үед тэд "хурал тогтоож", шаардлагатай өгөгдлийг солилцож, дараа нь уулзалтыг зогсоож, бие даасан гүйцэтгэлд буцаж ирдэг. Гэсэн хэдий ч системийг өөрөөр хэрэгжүүлсэн. Зорилтот даалгаврыг хүлээн авсны дараа тэр зорилтот даалгавар нь өөр даалгавартай уулзаж, дараа нь гурав дахь даалгавартай уулзсан ба зарим боловсруулалт дуустал үргэлжилсэн. Үүний дараа эдгээр бүх уулзалтууд дуусч, даалгавар бүр гүйцэтгэлдээ эргэн орох ёстой байв. Өөрөөр хэлбэл, бид дэлхийн хамгийн үнэтэй функц дуудлагын системтэй ажиллаж байсан бөгөөд энэ нь оролтын өгөгдлийн зарим хэсгийг боловсруулах явцад "олон даалгавар" үйл явцыг бүхэлд нь зогсоосон. Үүнээс өмнө зөвхөн дамжуулах чадвар маш бага байсан тул асуудал үүсгэдэггүй.
Уулзах хүсэлт тавьсан эсвэл дуусгахаар хүлээгдэж буй үед "даалгавар солих" боломжтой тул би энэ ажлын механизмыг тодорхойлсон. Өөрөөр хэлбэл, процессор гүйцэтгэхэд бэлэн байгаа өөр ажлыг боловсруулж эхлэх боломжтой. Нэг даалгавар өөр даалгавартай уулзахад бэлэн болсон үед огт өөр ажил хэрэгжиж эхлэх бөгөөд эцэст нь хяналт эхний уулзалт руу буцдаг. Даалгаврыг өөрчлөхөд хүргэдэг бусад үйл явдал тохиолдож болно; Ийм үйл явдлын нэг нь мутекс хэвлэх эсвэл гүйцэтгэх гэх мэт системийн функц руу залгах явдал юм.
Кодын аль мөр нь асуудал үүсгэж байгааг ойлгохын тулд би даалгаврын шилжүүлэгчийг өдөөхгүйгээр дараалсан мэдэгдлүүдийн дагуу ахиц дэвшлийг бүртгэх арга замыг хайж олох хэрэгтэй байсан бөгөөд энэ нь эвдрэлээс урьдчилан сэргийлэх болно. Тиймээс би давуу талыг ашиглаж чадаагүй Put_Line()оролт гаралтын үйлдлүүдийг хийхээс зайлсхийхийн тулд. Би тоологч хувьсагч эсвэл үүнтэй төстэй зүйлийг тохируулж болох ч дэлгэцэн дээр харуулахгүй бол утгыг нь яаж харах вэ?
Түүнчлэн, бүртгэлийг шалгаж үзэхэд зүрхний цохилтын мессежийг боловсруулах явцад хөлдсөн нь үйл явцын бүх I/O үйлдлийг хааж, бусад боловсруулалтыг гүйцэтгэхэд саад болж байсан ч бусад бие даасан ажлуудыг үргэлжлүүлэн гүйцэтгэж байсан нь тогтоогджээ. Өөрөөр хэлбэл, ажлыг бүхэлд нь хаагаагүй, зөвхөн (чухал) гинжин даалгаврууд байсан.
Энэ нь блоклох илэрхийлэлийг үнэлэхэд шаардлагатай сэжүүр байв.
Би даалгавар, тоологдсон төрөл, тэр төрлийн глобал хувьсагчийг агуулсан Ада багц хийсэн. Тооцоолж болох үг хэллэгүүд нь асуудалтай дарааллын тодорхой илэрхийлэлтэй холбоотой байв (жишээ нь. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), дараа нь глобал хувьсагчид харгалзах тооллогыг оноож өгсөн даалгаврын илэрхийлэлүүдийг оруулсан. Энэ бүхний объектын код нь зүгээр л санах ойд тогтмолыг хадгалдаг байсан тул түүнийг гүйцэтгэсний үр дүнд даалгавар солих магадлал маш бага байсан. Даалгаврыг буцааж солих үед (хэд хэдэн шалтгааны улмаас) буцаж ирэхээс илүү гүйцэтгэлийн үед блоклогдсон тул бид даалгаврыг сольж болох илэрхийлэлд голчлон сэжиглэж байсан.
Хяналтын даалгавар нь зүгээр л давталтаар гүйж, глобал хувьсагчийн утга өөрчлөгдсөн эсэхийг үе үе шалгадаг. Өөрчлөлт бүрт утгыг файлд хадгалсан. Дараа нь богино хүлээлт, шинэ шалгалт. Асуудлын талбарт даалгаврыг солих үед систем түүнийг гүйцэтгэхээр сонгосон үед л даалгавар гүйцэтгэгдэж байсан тул би хувьсагчийг файлд бичсэн. Энэ даалгаварт юу тохиолдсон нь бусад хамааралгүй блоклогдсон ажлуудад нөлөөлөхгүй.
Систем нь асуудалтай кодыг гүйцэтгэх цэгт хүрэхэд дараагийн илэрхийлэл бүр рүү шилжих үед глобал хувьсагчийг дахин тохируулна гэж тооцоолж байсан. Дараа нь даалгаврыг солиход хүргэдэг ямар нэг зүйл тохиолдох бөгөөд түүний гүйцэтгэлийн давтамж (10 Гц) хяналтын даалгавраас бага байдаг тул монитор глобал хувьсагчийн утгыг барьж, бичиж болно. Ердийн нөхцөлд би тооллогын дэд багцын давтагдах дарааллыг авч болно: даалгавар шилжих үеийн хувьсагчийн сүүлчийн утгууд. Өгөгдсөн үед глобал хувьсагч цаашид өөрчлөгдөхгүй бөгөөд хамгийн сүүлд бичигдсэн утга нь аль илэрхийлэл гүйцээгүйг харуулах болно.
Би кодыг хянах замаар ажиллуулсан. Тэр хөшиж орхив. Мөн хяналт цаг шиг ажилладаг байсан.
Лог нь хүлээгдэж буй дарааллыг агуулж байсан бөгөөд энэ нь мутекс дуудагдсаныг илтгэх утгаар тасалдсан. Unlock, мөн даалгавар дуусаагүй байна - өмнөх мянга мянган дуудлагатай адил.
Энэ үед Apex-ийн инженерүүд өөрсдийн кодоо халуунаар шинжилж, онолын хувьд түгжигдэх боломжтой газрыг mutex-д олжээ. Гэхдээ түүний магадлал маш бага байсан, учир нь зөвхөн тодорхой цаг үед тохиолдсон үйл явдлын тодорхой дараалал нь түгжрэлд хүргэж болзошгүй юм. Мерфигийн хууль, залуус аа, энэ бол Мерфигийн хууль.
Надад хэрэгтэй кодын хэсгийг хамгаалахын тулд би mutex функцийн дуудлагуудыг (OS-ийн mutex функц дээр суурилагдсан) жижиг уугуул Ada mutex багцаар сольсон бөгөөд энэ хэсэг рүү mutex хандалтыг хянах боломжтой болсон.
Би үүнийг код руу оруулаад тест хийсэн. Долоон цагийн дараа код ажиллаж байсан.
Миний кодыг Rational-д илгээсэн бөгөөд тэд үүнийг эмхэтгэж, задалж, асуудалтай mutex функцүүдэд ашигладаг арга барилыг ашиглаагүй эсэхийг шалгасан.
Энэ бол миний карьерийн хамгийн олон хүнтэй кодын тойм байсан 🙂 Надтай хамт өрөөнд арав орчим инженер, менежер байсан, өөр арав хүн хурлын дуудлагад байсан - тэд бүгд 20 орчим мөр кодыг шалгасан.
Кодыг хянаж үзээд, шинэ гүйцэтгэгдэх файлуудыг цуглуулж, албан ёсны регрессийн туршилтанд оруулсан. Хэдэн долоо хоногийн дараа тооллогын туршилт амжилттай болж, пуужин хөөрөв.
За, энэ бүхэн сайхан байна, гэхдээ энэ түүхийн утга учир юу вэ?
Энэ бол үнэхээр зэвүүн асуудал байсан. Хэдэн зуун мянган мөр код, зэрэгцээ гүйцэтгэл, арав гаруй харилцан үйлчлэлийн процесс, муу архитектур, хэрэгжилт муу, суулгагдсан системийн интерфейс, олон сая доллар зарцуулсан. Ямар ч дарамт, тийм ээ.
Би зөөвөрлөх ажлыг хийж байхдаа олны анхаарлын төвд байсан ч энэ асуудал дээр ганцаараа ажилласангүй. Гэхдээ би үүнийг хийсэн ч гэсэн хэдэн зуун мянган мөр кодыг бүгдийг нь ойлгосон, бүр алгассан гэсэн үг биш. Код, бүртгэлийг орон даяар инженерүүд шинжилсэн боловч бүтэлгүйтлийн шалтгааны талаархи таамаглалыг надад хэлэхэд би үүнийг няцаахад хагас минут л зарцуулсан. Тэгээд надаас онолыг шинжлэхийг хүсэхэд би өөр хүнд дамжуулдаг байсан, учир нь эдгээр инженерүүд буруу замаар явж байгаа нь надад илт байсан. Ихэмсэг сонсогдож байна уу? Тийм ээ, энэ үнэн, гэхдээ би өөр шалтгаанаар таамаглал, хүсэлтийг няцаасан.
Би асуудлын мөн чанарыг ойлгосон. Би яг хаана, яагаад болоод байгааг мэдэхгүй ч юу болоод байгааг мэдэж байсан.
Олон жилийн турш би маш их мэдлэг, туршлага хуримтлуулсан. Би Ада-г ашиглах анхдагчдын нэг байсан бөгөөд түүний давуу болон сул талуудыг ойлгосон. Ада ажиллах цагийн номын сангууд даалгавруудыг хэрхэн зохицуулж, зэрэгцээ гүйцэтгэлтэй харьцдагийг би мэднэ. Мөн би доод түвшний програмчлалыг санах ой, регистр, ассемблерийн түвшинд ойлгодог. Өөрөөр хэлбэл, би салбартаа гүн гүнзгий мэдлэгтэй. Тэгээд би асуудлын шалтгааныг олохын тулд тэдгээрийг ашигласан. Би зөвхөн алдааг тойроод зогсохгүй, үүнийг маш мэдрэмтгий ажиллах үеийн орчинд хэрхэн олохыг ойлгосон.
Кодтой тэмцэх ийм түүхүүд нь ийм тэмцлийн онцлог, нөхцөлийг сайн мэдэхгүй хүмүүст тийм ч сонирхолтой биш юм. Гэхдээ эдгээр түүхүүд нь үнэхээр хэцүү асуудлыг шийдвэрлэхэд юу хэрэгтэйг ойлгоход тусалдаг.
Үнэхээр хэцүү асуудлуудыг шийдэхийн тулд та зүгээр нэг програмист биш байх хэрэгтэй. Та кодын "хувь заяа", хүрээлэн буй орчинтойгоо хэрхэн харьцаж, хүрээлэн буй орчин өөрөө хэрхэн ажилладагийг ойлгох хэрэгтэй.
Дараа нь та өөрийн гэсэн сүйрсэн амралтын долоо хоногтой болно.
Үргэлжлүүлэх.
Эх сурвалж: www.habr.com