პროგრამისტებისა და ინჟინრების ფოლკლორი (ნაწილი 1)

ეს არის ისტორიების შერჩევა ინტერნეტიდან იმის შესახებ, თუ როგორ აქვთ შეცდომები ხანდახან სრულიად წარმოუდგენელი გამოვლინებები. ალბათ თქვენც გაქვთ სათქმელი.

მანქანის ალერგია ვანილის ნაყინზე

ამბავი ინჟინრებისთვის, რომელთაც ესმით, რომ ცხადი ყოველთვის არ არის პასუხი და რომ რაც არ უნდა შორს წასული ფაქტები ჩანდეს, ისინი მაინც ფაქტებია. General Motors Corporation-ის პონტიაკის განყოფილებამ მიიღო საჩივარი:

უკვე მეორედ გწერ და არ გადანაშაულებ, რომ არ მპასუხობ, რადგან გიჟურად ჟღერს. ჩვენს ოჯახს აქვს ტრადიცია, რომ ყოველ ღამე სადილის შემდეგ მიირთვათ ნაყინი. ნაყინის სახეობები ყოველ ჯერზე იცვლება და სადილის შემდეგ მთელი ოჯახი ირჩევს რომელი ნაყინი ვიყიდო, რის შემდეგაც მაღაზიაში მივდივარ. ახლახან ვიყიდე ახალი პონტიაკი და მას შემდეგ ჩემი მოგზაურობები ნაყინის მისაღებად პრობლემად იქცა. ხომ ხედავ, ყოველთვის, როცა ვანილის ნაყინს ვყიდულობ და მაღაზიიდან ვბრუნდები, მანქანა არ დგება. სხვა ნაყინი რომ მოვიტანო, მანქანა უპრობლემოდ დადის. მინდა დავსვა სერიოზული კითხვა, რაც არ უნდა სულელურად ჟღერდეს: „რა არის ის პონტიაკში, რომ ის არ იწყება, როცა ვანილის ნაყინი მომაქვს, მაგრამ ადვილად იწყება, როცა ნაყინის სხვა არომატი მოვიტან?“

როგორც წარმოგიდგენიათ, სამმართველოს პრეზიდენტი წერილს სკეპტიკურად უყურებდა. თუმცა, ყოველი შემთხვევისთვის, ინჟინერი გავგზავნე შესამოწმებლად. მას გაუკვირდა, რომ ლამაზ უბანში მცხოვრები მდიდარი, განათლებული კაცი დახვდა. ისინი შეთანხმდნენ, რომ სადილის შემდეგ დაუყოვნებლივ შეხვედროდნენ, რომ ორივენი მაღაზიაში წასულიყვნენ ნაყინისთვის. იმ საღამოს ვანილი იყო და მანქანაში რომ დაბრუნდნენ, ის არ დაწყებულა.

ინჟინერი კიდევ სამი საღამოს მოვიდა. პირველად ნაყინი შოკოლადი იყო. მანქანა დაიძრა. მეორედ იყო მარწყვის ნაყინი. მანქანა დაიძრა. მესამე საღამოს მან ვანილის აღება სთხოვა. მანქანა არ დაძრა.

რაციონალურად მსჯელობისას ინჟინერმა უარი თქვა იმის დაჯერებაზე, რომ მანქანა ალერგიული იყო ვანილის ნაყინზე. ამიტომ, მანქანის მფლობელს შევთანხმდი, რომ მანამდე გააგრძელებდა ვიზიტებს, სანამ პრობლემის გადაწყვეტას არ იპოვიდა. და გზაში მან დაიწყო ჩანაწერების აღება: ჩაწერა ყველა ინფორმაცია, დღის დრო, ბენზინის ტიპი, მაღაზიიდან ჩამოსვლისა და დაბრუნების დრო და ა.შ.

ინჟინერი მალევე მიხვდა, რომ მანქანის პატრონი ნაკლებ დროს უთმობდა ვანილის ნაყინის ყიდვას. მიზეზი მაღაზიაში საქონლის განლაგება გახდა. ვანილის ნაყინი ყველაზე პოპულარული იყო და ინახებოდა ცალკე საყინულეში მაღაზიის წინა მხარეს, რათა გაადვილებულიყო მისი პოვნა. და ყველა სხვა ჯიში იყო მაღაზიის უკანა მხარეს და გაცილებით მეტი დრო დასჭირდა სწორი ჯიშის პოვნას და გადახდას.

ახლა კითხვა იყო ინჟინრისთვის: რატომ არ დაიწყო მანქანა, თუ ნაკლები დრო გავიდა ძრავის გამორთვის მომენტიდან? ვინაიდან პრობლემა იყო დრო და არა ვანილის ნაყინი, ინჟინერმა სწრაფად იპოვა პასუხი: ეს იყო გაზის საკეტი. ეს ხდებოდა ყოველ საღამოს, მაგრამ როდესაც მანქანის მფლობელი მეტ დროს უთმობდა ნაყინის ძებნას, ძრავმა საკმარისად გაცივდა და ადვილად ამუშავდა. და როდესაც კაცმა იყიდა ვანილის ნაყინი, ძრავა ჯერ კიდევ ძალიან ცხელი იყო და გაზის საკეტს არ ჰქონდა დრო დაშლა.

მორალი: სრულიად გიჟური პრობლემებიც კი ზოგჯერ რეალურია.

Crash Bandicoot

მტკივნეულია ამის გამოცდილება. როგორც პროგრამისტი, თქვენ შეჩვეული ხართ დაადანაშაულოთ ​​თქვენი კოდი ჯერ, მეორე, მესამე... და სადღაც ათი ათასში ადანაშაულებთ კომპილერს. და უფრო ქვემოთ სიაში თქვენ უკვე ადანაშაულებთ აღჭურვილობას.

აქ არის ჩემი ამბავი ტექნიკის შეცდომის შესახებ.

თამაშისთვის Crash Bandicoot დავწერე კოდი ჩატვირთვის და მეხსიერების ბარათზე შესანახად. ასეთი თვითკმაყოფილი თამაშების დეველოპერისთვის ეს პარკში გასეირნებას ჰგავდა: მეგონა სამუშაოს რამდენიმე დღე დასჭირდებოდა. თუმცა, მე დავასრულე კოდის გამართვა ექვსი კვირის განმავლობაში. გზაში სხვა პრობლემებიც მოვაგვარე, მაგრამ რამდენიმე დღეში ერთხელ ვუბრუნდებოდი ამ კოდს რამდენიმე საათით. აგონია იყო.

სიმპტომი ასე გამოიყურებოდა: როდესაც ინახავთ თამაშის მიმდინარე რეჟიმს და წვდებით მეხსიერების ბარათს, ყველაფერი თითქმის ყოველთვის კარგად მიდის... მაგრამ ხანდახან წაკითხვისა და ჩაწერის ოპერაციების დრო ამოიწურება აშკარა მიზეზის გარეშე. ხანმოკლე ჩანაწერი ხშირად აზიანებს მეხსიერების ბარათს. როდესაც მოთამაშე ცდილობს გადარჩენას, ის არა მხოლოდ ვერ ახერხებს გადარჩენას, არამედ ანადგურებს რუკას. სისულელე.

გარკვეული პერიოდის შემდეგ, Sony-ის ჩვენმა პროდიუსერმა, კონი ავტობუსმა, პანიკა დაიწყო. ჩვენ ვერ გავაგზავნეთ თამაში ამ შეცდომით და ექვსი კვირის შემდეგ მე ვერ გავიგე რა იწვევდა პრობლემას. Connie-ს მეშვეობით დავუკავშირდით PS1-ის სხვა დეველოპერებს: ვინმეს თუ შეგხვედრიათ მსგავსი რამ? არა. მეხსიერების ბარათზე პრობლემა არავის ჰქონია.

როდესაც არ გაქვთ იდეები გამართვის შესახებ, რჩება ერთადერთი მიდგომა „გაყავით და დაიპყროთ“: წაშალეთ უფრო და უფრო მეტი კოდი გაუმართავი პროგრამიდან, სანამ არ დარჩება შედარებით მცირე ფრაგმენტი, რომელიც კვლავ იწვევს პრობლემას. ანუ თქვენ წყვეტთ პროგრამას ნაწილ-ნაწილ, სანამ არ დარჩება ის ნაწილი, რომელიც შეიცავს შეცდომას.

მაგრამ საქმე იმაშია, რომ ძალიან რთულია ვიდეო თამაშიდან ნაჭრების ამოჭრა. როგორ გავუშვათ ის, თუ წაშალეთ კოდი, რომელიც მიბაძავს გრავიტაციას? ან ხატავს პერსონაჟებს?

აქედან გამომდინარე, ჩვენ უნდა შევცვალოთ მთელი მოდულები ნაკვთებით, რომლებიც თითქოს რაღაც სასარგებლოს აკეთებენ, მაგრამ რეალურად გავაკეთოთ რაღაც ძალიან მარტივი, რომელიც არ შეიცავს შეცდომებს. ასეთი ყავარჯნები უნდა დავწეროთ, რომ თამაშმა მაინც იმუშაოს. ეს ნელი და მტკივნეული პროცესია.

მოკლედ, გავაკეთე. მე ამოვიღე კოდის უფრო და უფრო მეტი ნაწილი, სანამ არ დამრჩა საწყისი კოდი, რომელიც აკონფიგურირებს სისტემას თამაშის გასაშვებად, ინიციალიზაციას უკეთებს რენდერის აპარატურას და ა.შ. რა თქმა უნდა, ამ ეტაპზე შენახვის და ჩატვირთვის მენიუს ვერ შევქმნიდი, რადგან ყველა გრაფიკული კოდისთვის უნდა შემექმნა stub. მაგრამ მე შემეძლო პრეტენზია მომხმარებლად ვიყენებდი (უხილავი) შენახვისა და ჩატვირთვის ეკრანს და ვთხოვე შენახვა და შემდეგ მეხსიერების ბარათზე ჩაწერა.

ამან დამიტოვა კოდის პატარა ნაწილი, რომელსაც ჯერ კიდევ ჰქონდა ზემოაღნიშნული პრობლემა - მაგრამ ეს მაინც შემთხვევით ხდებოდა! ყველაზე ხშირად ყველაფერი კარგად მუშაობდა, მაგრამ ზოგჯერ იყო ხარვეზები. თამაშის თითქმის ყველა კოდი წავშალე, მაგრამ შეცდომა მაინც ცოცხალი იყო. ეს იყო დამაბნეველი: დარჩენილმა კოდმა რეალურად არაფერი გააკეთა.

რაღაც მომენტში, ალბათ დილის სამ საათზე, აზრმა გამიელვა. წაკითხვის და ჩაწერის (შეყვანის/გამოსვლის) ოპერაციები მოიცავს შესრულების ზუსტ დროს. როდესაც მუშაობთ მყარ დისკთან, მეხსიერების ბარათთან ან Bluetooth მოდულთან, დაბალი დონის კოდი, რომელიც პასუხისმგებელია კითხვასა და წერაზე, ამას აკეთებს საათის იმპულსების შესაბამისად.

საათის დახმარებით, მოწყობილობა, რომელიც უშუალოდ არ არის დაკავშირებული პროცესორთან, სინქრონიზებულია პროცესორზე შემსრულებელ კოდთან. საათი განსაზღვრავს ბაუდის სიჩქარეს - მონაცემთა გადაცემის სიჩქარეს. თუ არის დაბნეულობა დროებთან დაკავშირებით, მაშინ ან აპარატურა ან პროგრამული უზრუნველყოფა, ან ორივე, ასევე დაბნეულია. და ეს ძალიან ცუდია, რადგან მონაცემები შეიძლება დაზიანდეს.

რა მოხდება, თუ ჩვენს კოდში რაღაც აბნევს ვადებს? მე შევამოწმე ყველაფერი, რაც დაკავშირებული იყო სატესტო პროგრამის კოდში და შევამჩნიე, რომ ჩვენ დავაყენეთ პროგრამირებადი ტაიმერი PS1-ში 1 kHz-ზე (1000 ტიკი წამში). ეს საკმაოდ ბევრია; სტანდარტულად, როდესაც კონსოლი იწყება, ის მუშაობს 100 ჰც-ზე. და თამაშების უმეტესობა იყენებს ამ სიხშირეს.

ენდიმ, თამაშის შემქმნელმა, დააყენა ტაიმერი 1 kHz-ზე, რათა მოძრაობები უფრო ზუსტად გამოითვალოს. ენდი მიდრეკილია ზღვარზე გადასვლისკენ და თუ გრავიტაციას მივბაძავთ, ამას რაც შეიძლება ზუსტად ვაკეთებთ!

მაგრამ რა მოხდება, თუ ტაიმერის დაჩქარება გარკვეულწილად იმოქმედებდა პროგრამის საერთო დროზე და, შესაბამისად, საათზე, რომელიც არეგულირებს მეხსიერების ბარათის ბაუდის სიჩქარეს?

მე კომენტარს გავაკეთე ტაიმერის კოდი. შეცდომა აღარ განმეორდა. მაგრამ ეს არ ნიშნავს იმას, რომ ჩვენ გამოვასწორეთ, რადგან მარცხი შემთხვევით მოხდა. თუ უბრალოდ გამიმართლა?

რამდენიმე დღის შემდეგ ისევ ჩავატარე ექსპერიმენტი სატესტო პროგრამით. შეცდომა არ განმეორდა. მე დავბრუნდი თამაშის სრულ კოდების ბაზაზე და შევცვალე შენახვისა და ჩატვირთვის კოდი ისე, რომ პროგრამირებადი ტაიმერი აღედგინა თავდაპირველ მნიშვნელობაზე (100Hz) მეხსიერების ბარათზე წვდომამდე, შემდეგ კი დაბრუნებულიყო 1kHz-ზე. ავარიები აღარ ყოფილა.

მაგრამ რატომ მოხდა ეს?

ისევ სატესტო პროგრამას დავუბრუნდი. შევეცადე მეპოვა რაიმე ნიმუში შეცდომის წარმოშობაში 1 kHz ტაიმერით. საბოლოოდ შევამჩნიე, რომ შეცდომა ჩნდება, როდესაც ვინმე თამაშობს PS1 კონტროლერთან. ვინაიდან მე იშვიათად გავაკეთებდი ამას - რატომ მჭირდება კონტროლერი შენახვისა და ჩატვირთვის კოდის ტესტირებისას? - არც კი შემიმჩნევია ეს დამოკიდებულება. მაგრამ ერთ დღეს ჩვენი ერთ-ერთი მხატვარი მელოდებოდა ტესტის დასრულებას - ალბათ ვლანძღავდი იმ მომენტში - და ნერვიულად მოტრიალდა კონტროლერი ხელში. მოხდა შეცდომა. "მოიცადე, რა?!" კარგი, გააკეთე კიდევ ერთხელ! ”

როდესაც მივხვდი, რომ ეს ორი მოვლენა ერთმანეთთან იყო დაკავშირებული, შეცდომის გამეორება მარტივად მოვახერხე: დავიწყე მეხსიერების ბარათზე ჩაწერა, კონტროლერი გადავიტანე და მეხსიერების ბარათი გავაფუჭე. ჩემთვის ეს ტექნიკის შეცდომას ჰგავდა.

კონისთან მივედი და ჩემი აღმოჩენის შესახებ ვუთხარი. მან ინფორმაცია გადასცა ერთ-ერთ ინჟინერს, რომელმაც დააპროექტა PS1. ”შეუძლებელია,” უპასუხა მან, ”ეს არ შეიძლება იყოს ტექნიკის პრობლემა.” კონის ვთხოვე ჩვენთვის საუბრის მოწყობა.

ინჟინერმა დამირეკა და მისი გატეხილი ინგლისურით და ჩემი (უკიდურესად) გატეხილი იაპონურით ვიკამათეთ. ბოლოს მე ვთქვი: „ნება მომეცით გამომიგზავნოთ ჩემი 30 ხაზიანი ტესტის პროგრამა, სადაც კონტროლერის გადაადგილება იწვევს შეცდომას“. ის დათანხმდა. თქვა, რომ ეს იყო დროის კარგვა და რომ ის საშინლად იყო დაკავებული ახალ პროექტზე მუშაობით, მაგრამ დათმობდა, რადგან ჩვენ ვიყავით ძალიან მნიშვნელოვანი დეველოპერი Sony-სთვის. მე გავასუფთავე ჩემი სატესტო პროგრამა და გავუგზავნე მას.

მეორე საღამოს (ჩვენ ვიყავით ლოს-ანჯელესში, ის კი ტოკიოში) დამირეკა და ბოდიში მომიხადა. ეს იყო ტექნიკის პრობლემა.

არ ვიცი კონკრეტულად რა ხარვეზი იყო, მაგრამ სონის შტაბ-ბინაში რაც გავიგე, თუ ტაიმერი საკმარისად მაღალ მნიშვნელობაზე დააყენე, ის ხელს უშლის კომპონენტებს დედაპლატზე ტაიმერის ბროლის სიახლოვეს. ერთ-ერთი მათგანი იყო მეხსიერების ბარათის ბაუდ სიჩქარის კონტროლერი, რომელიც ასევე ადგენდა კონტროლერების ბაუდის სიხშირეს. მე არ ვარ ინჟინერი, ასე რომ, შესაძლოა, რაღაც გავაფუჭო.

მაგრამ მთავარი ის არის, რომ იყო ჩარევა კომპონენტებს შორის დედაპლატზე. ხოლო კონტროლერის პორტისა და მეხსიერების ბარათის პორტის საშუალებით მონაცემთა ერთდროულად გადაცემისას ტაიმერით, რომელიც მუშაობს 1 kHz-ზე, დაიკარგა ბიტები, დაიკარგა მონაცემები და დაზიანდა ბარათი.

ცუდი ძროხები

1980-იან წლებში ჩემმა მენტორმა სერგეიმ დაწერა პროგრამული უზრუნველყოფა SM-1800-ისთვის, PDP-11-ის საბჭოთა კლონისთვის. ეს მიკროკომპიუტერი ახლახან დამონტაჟდა რკინიგზის სადგურზე სვერდლოვსკის მახლობლად, მნიშვნელოვანი სატრანსპორტო კერა სსრკ-ში. ახალი სისტემა შეიქმნა ვაგონებისა და სატვირთო მიმოსვლის გადასაყვანად. მაგრამ ის შეიცავდა შემაშფოთებელ შეცდომას, რამაც გამოიწვია შემთხვევითი ავარია და ავარია. ვარდნა ყოველთვის ხდებოდა, როცა ვინმე საღამოს სახლში მიდიოდა. მაგრამ მეორე დღეს საფუძვლიანი გამოკვლევის მიუხედავად, კომპიუტერი სწორად მუშაობდა ყველა მექანიკურ და ავტომატურ ტესტებში. ეს ჩვეულებრივ მიუთითებს რასის მდგომარეობაზე ან სხვა კონკურენტულ შეცდომაზე, რომელიც ხდება გარკვეულ პირობებში. გვიან ღამით ზარებით დაღლილმა სერგეიმ გადაწყვიტა ბოლომდე ჩასულიყო და, პირველ რიგში, გაეგო, რა პირობებმა გამოიწვია მარშალინგის ეზოში კომპიუტერის გაფუჭება.

პირველ რიგში, მან შეაგროვა ყველა აუხსნელი დაცემის სტატისტიკა და შექმნა გრაფიკი თარიღისა და დროის მიხედვით. ნიმუში აშკარა იყო. კიდევ რამდენიმე დღის დაკვირვების შემდეგ, სერგეი მიხვდა, რომ მას ადვილად შეეძლო მომავალი სისტემის წარუმატებლობის დროის პროგნოზირება.

მან მალევე გაიგო, რომ შეფერხებები მხოლოდ მაშინ ხდებოდა, როდესაც სადგური ახარისხებდა მსხვილფეხა პირუტყვის მატარებელს ჩრდილოეთ უკრაინიდან და დასავლეთ რუსეთიდან, რომლებიც მიემართებოდნენ ახლომდებარე სასაკლაოსკენ. ეს თავისთავად უცნაური იყო, რადგან სასაკლაოს ამარაგებდნენ ბევრად უფრო ახლოს, ყაზახეთში მდებარე ფერმები.

ჩერნობილის ატომური ელექტროსადგური აფეთქდა 1986 წელს და რადიოაქტიურმა ვარდნამ მიმდებარე ტერიტორიები დაუსახლებელი გახადა. დაბინძურებული იყო ჩრდილოეთ უკრაინის, ბელორუსის და დასავლეთ რუსეთის უზარმაზარი ტერიტორიები. ეჭვმიტანილი იყო რადიაციის მაღალი დონე შემოსულ ვაგონებში, სერგეიმ შეიმუშავა მეთოდი ამ თეორიის შესამოწმებლად. მოსახლეობას დოზიმეტრების ქონა აეკრძალა, ამიტომ სერგეი რკინიგზის სადგურზე რამდენიმე სამხედროსთან ერთად დარეგისტრირდა. არაყის რამდენიმე დალევის შემდეგ მან მოახერხა ჯარისკაცის დარწმუნება, რომ გაზომა რადიაციის დონე ერთ-ერთ საეჭვო ვაგონში. აღმოჩნდა, რომ დონე რამდენჯერმე აღემატება ნორმალურ მნიშვნელობებს.

პირუტყვი არამარტო ასხივებდა უამრავ რადიაციას, მისი დონე იმდენად მაღალი იყო, რომ ამან გამოიწვია SM-1800-ის მეხსიერების ბიტების შემთხვევითი დაკარგვა, რომელიც მდებარეობდა სადგურის გვერდით შენობაში.

სსრკ-ში საკვების დეფიციტი იყო და ხელისუფლებამ გადაწყვიტა ჩერნობილის ხორცი შეერევა ქვეყნის სხვა რეგიონების ხორცთან. ამან შესაძლებელი გახადა რადიოაქტიურობის საერთო დონის შემცირება ღირებული რესურსების დაკარგვის გარეშე. ამის შესახებ შეიტყო, სერგეიმ მაშინვე შეავსო დოკუმენტები ემიგრაციაში. და კომპიუტერის ავარია თავისთავად შეჩერდა, როდესაც რადიაციის დონე დროთა განმავლობაში შემცირდა.

მილების მეშვეობით

ერთხელ, Movietech Solutions-მა შექმნა პროგრამული უზრუნველყოფა კინოთეატრებისთვის, რომელიც განკუთვნილი იყო ბუღალტრული აღრიცხვის, ბილეთების გაყიდვისა და ზოგადი მენეჯმენტისთვის. ფლაგმანი აპლიკაციის DOS ვერსია საკმაოდ პოპულარული იყო ჩრდილოეთ ამერიკაში მცირე და საშუალო ზომის კინოთეატრების ქსელებში. ასე რომ, გასაკვირი არ არის, რომ როდესაც გამოცხადდა Windows 95-ის ვერსია, რომელიც ინტეგრირებულია უახლეს სენსორულ ეკრანებთან და თვითმომსახურების კიოსკებთან და აღჭურვილია ყველა სახის საანგარიშო ინსტრუმენტებით, ის ასევე სწრაფად გახდა პოპულარული. ყველაზე ხშირად განახლება უპრობლემოდ მიმდინარეობდა. ადგილობრივმა IT პერსონალმა დააინსტალირა ახალი აღჭურვილობა, გადაიტანა მონაცემები და ბიზნესი გაგრძელდა. გარდა იმ შემთხვევისა, როცა ეს არ გაგრძელებულა. როდესაც ეს მოხდა, კომპანია გამოგზავნიდა ჯეიმს, მეტსახელად "დამლაგებელი".

მიუხედავად იმისა, რომ მეტსახელი ბოროტ ტიპს მიანიშნებს, დამლაგებელი მხოლოდ ინსტრუქტორის, ინსტალატორისა და ჯეკ-of-all-trades-ის კომბინაციაა. ჯეიმსი რამდენიმე დღეს ატარებდა კლიენტის საიტზე ყველა კომპონენტთან ერთად და შემდეგ კიდევ რამდენიმე დღეს ასწავლიდა პერსონალს ახალი სისტემის გამოყენებას, აგვარებდა ტექნიკის ნებისმიერ პრობლემას, რომელიც წარმოიშვა და არსებითად ეხმარებოდა პროგრამულ უზრუნველყოფას მისი ჩვილობის პერიოდში.

ამიტომ, გასაკვირი არ არის, რომ ამ დაძაბულ დროს ჯეიმსი დილით მივიდა ოფისში და სანამ თავის მაგიდას მიაღწევდა, მას კოფეინით სავსე მენეჯერი მიესალმა.

”მეშინია, რომ რაც შეიძლება მალე უნდა წახვიდე ანაპოლისში, ნოვა შოტლანდიაში.” მათი მთელი სისტემა დაიშალა და ინჟინრებთან ერთი ღამის მუშაობის შემდეგ, ჩვენ ვერ ვხვდებით, რა მოხდა. როგორც ჩანს, ქსელი ვერ მოხერხდა სერვერზე. მაგრამ მხოლოდ მას შემდეგ, რაც სისტემა რამდენიმე წუთის განმავლობაში მუშაობდა.

- ძველ სისტემაში არ დაბრუნდნენ? - სრულიად სერიოზულად უპასუხა ჯეიმსმა, თუმცა ძალაუნებურად გაოცებისგან თვალები გააფართოვა.

— ზუსტად: მათმა IT სპეციალისტმა „შეცვალა პრიორიტეტები“ და გადაწყვიტა წასულიყო ძველ სერვერთან. ჯეიმს, მათ დააინსტალირეს სისტემა ექვს საიტზე და უბრალოდ გადაიხადეს პრემიუმ მხარდაჭერა და მათი ბიზნესი ახლა მართულია ისე, როგორც 1950-იან წლებში იყო.

ჯეიმსი ოდნავ გასწორდა.

- ეს სხვა საქმეა. კარგი, დავიწყოთ.

როდესაც ის ანაპოლისში ჩავიდა, პირველი რაც გააკეთა, დამკვეთის პირველი თეატრის პოვნა იყო, რომელსაც პრობლემა ჰქონდა. აეროპორტში გადაღებულ რუკაზე ყველაფერი წესიერად გამოიყურებოდა, მაგრამ სასურველი მისამართის მიმდებარე ტერიტორია საეჭვოდ გამოიყურებოდა. გეტო არა, მაგრამ ფილმ ნუარს მოგაგონებთ. როდესაც ჯეიმსი გაჩერებული იყო ქალაქის ცენტრში, მეძავი მიუახლოვდა მას. ანაპოლისის ზომის გათვალისწინებით, ის, სავარაუდოდ, ერთადერთი იყო მთელ ქალაქში. მისმა გარეგნობამ მაშინვე გაახსენა ცნობილი პერსონაჟი, რომელიც დიდ ეკრანზე ფულზე სექსს სთავაზობდა. არა, არა ჯულია რობერტსზე, არამედ ჯონ ვოიტზე [ალუზია ფილმზე "შუაღამის კოვბოი" - დაახლ. შესახვევი].

მეძავის გზაზე გაგზავნის შემდეგ ჯეიმსი კინოში წავიდა. მიმდებარე ტერიტორია გაუმჯობესდა, მაგრამ მაინც დაცლილის შთაბეჭდილებას ტოვებდა. არა ის, რომ ჯეიმსი ძალიან ღელავდა. ის ადრე იყო სავალალო ადგილებში. და ეს იყო კანადა, სადაც მძარცველებიც კი არიან საკმარისად თავაზიანი, რომ თქვან "მადლობა" თქვენი საფულის აღების შემდეგ.

კინოთეატრის გვერდითი შესასვლელი დაბინძურებულ ხეივანში იყო. ჯეიმსი კარისკენ წავიდა და დააკაკუნა. მალე ატყდა და ოდნავ გაიხსნა.

-დამლაგებელი ხარ? - შიგნიდან უხეში ხმა გაისმა.

-კი მე ვარ... ყველაფრის გამოსასწორებლად მოვედი.

ჯეიმსი კინოს ფოიეში შევიდა. როგორც ჩანს, სხვა არჩევანი არ ჰქონდათ, თანამშრომლებმა დაიწყეს სტუმრებისთვის ქაღალდის ბილეთების დარიგება. ამან გაართულა ფინანსური ანგარიშგება, რომ აღარაფერი ვთქვათ უფრო საინტერესო დეტალებზე. მაგრამ პერსონალი ჯეიმსს შვებით მიესალმა და მაშინვე სერვერის ოთახში წაიყვანეს.

ერთი შეხედვით ყველაფერი კარგად იყო. ჯეიმსი შევიდა სერვერზე და შეამოწმა ჩვეულებრივი საეჭვო ადგილები. Არაა პრობლემა. თუმცა, სიფრთხილის გამო, ჯეიმსმა დახურა სერვერი, შეცვალა ქსელის ბარათი და დააბრუნა სისტემა. მან მაშინვე სრულად დაიწყო მუშაობა. თანამშრომლებმა ისევ დაიწყეს ბილეთების გაყიდვა.

ჯეიმსმა დაურეკა მარკს და შეატყობინა მას სიტუაცია. ძნელი არ არის იმის წარმოდგენა, რომ ჯეიმსს შეიძლება უნდოდეს დარჩეს და დაინახოს, მოხდება თუ არა რაიმე მოულოდნელი. კიბეებზე ჩავიდა და თანამშრომლებს დაუწყო კითხვა რა მოხდა. ცხადია, სისტემამ მუშაობა შეწყვიტა. გამორთეს და ჩართო, ყველაფერი მუშაობდა. მაგრამ 10 წუთის შემდეგ სისტემა დაიშალა.

სწორედ ამ მომენტში მოხდა მსგავსი რამ. მოულოდნელად ბილეთების სისტემამ შეცდომების სროლა დაიწყო. თანამშრომლებმა ამოისუნთქეს და ქაღალდის ბილეთები აიღეს და ჯეიმსი სწრაფად გავიდა სერვერის ოთახში. ყველაფერი კარგად გამოიყურებოდა სერვერთან.

მერე ერთ-ერთი თანამშრომელი შემოვიდა.

- სისტემა ისევ მუშაობს.

ჯეიმსი გაოცებული იყო, რადგან არაფერი გაუკეთებია. უფრო ზუსტად, არაფერი, რაც სისტემას ამუშავებს. ის გამოვიდა, აიღო ტელეფონი და დარეკა თავისი კომპანიის მხარდაჭერის ხაზზე. მალე იგივე თანამშრომელი შევიდა სერვერის ოთახში.

- სისტემა გათიშულია.

ჯეიმსმა სერვერს გადახედა. ეკრანზე მოცეკვავე მრავალფეროვანი ფორმების საინტერესო და ნაცნობი ნიმუში - ქაოტურად ტრიალი და ერთმანეთში გადახლართული მილები. ჩვენ ყველამ ვნახეთ ეს ეკრანმზოგი რაღაც მომენტში. ლამაზად იყო გადმოცემული და ფაქტიურად ჰიპნოზური.

ჯეიმსმა დააჭირა ღილაკს და ნიმუში გაქრა. სასწრაფოდ მივიდა ბილეთების ოფისში და გზად მასთან დაბრუნებული თანამშრომელი დახვდა.

- სისტემა ისევ მუშაობს.

თუ თქვენ შეგიძლიათ გააკეთოთ გონებრივი სახის პალმის გაკეთება, ეს არის ზუსტად ის, რაც ჯეიმსმა გააკეთა. Ეკრანმზოგი. ის იყენებს OpenGL-ს. და ამიტომ, ოპერაციის დროს, ის მოიხმარს სერვერის პროცესორის ყველა რესურსს. შედეგად, ყოველი ზარი სერვერზე მთავრდება დროის ამოწურვით.

ჯეიმსი დაბრუნდა სერვერის ოთახში, შევიდა სისტემაში და შეცვალა ეკრანმზოგი ლამაზი მილებით ცარიელი ეკრანით. ანუ სქრინსეივერის ნაცვლად, რომელიც მოიხმარს პროცესორის რესურსების 100%-ს, დავაინსტალირე სხვა რომელიც არ მოიხმარს რესურსებს. შემდეგ 10 წუთი დაველოდე, რათა გადამემოწმებინა ჩემი ვარაუდი.

როდესაც ჯეიმსი მივიდა შემდეგ კინოთეატრში, აინტერესებდა, როგორ აეხსნა თავის მენეჯერს, რომ მან ახლახან გაიარა 800 კმ ეკრანმზოგის გამორთვისთვის.

კრახი მთვარის გარკვეულ ფაზაში

Ნამდვილი ამბავი. ერთ დღეს გაჩნდა პროგრამული ხარვეზი, რომელიც დამოკიდებული იყო მთვარის ფაზაზე. იყო პატარა რუტინა, რომელიც ჩვეულებრივ გამოიყენებოდა MIT-ის სხვადასხვა პროგრამებში მთვარის ნამდვილ ფაზასთან მიახლოების გამოსათვლელად. GLS-მა ჩააშენა ეს რუტინა LISP პროგრამაში, რომელიც ფაილის დაწერისას გამოსცემდა ხაზს დაახლოებით 80 სიმბოლოს დროის ნიშნულით. ძალიან იშვიათი იყო, რომ შეტყობინების პირველი სტრიქონი ძალიან გრძელი დამთავრებულიყო და შემდეგ სტრიქონზე მივიდეს. და როდესაც პროგრამამ მოგვიანებით წაიკითხა ეს ფაილი, დაწყევლა. პირველი ხაზის სიგრძე დამოკიდებული იყო ზუსტ თარიღსა და დროს, ასევე ფაზის სპეციფიკაციის ხანგრძლივობაზე დროის ანაბეჭდის დაბეჭდვის დროს. ანუ შეცდომა ფაქტიურად მთვარის ფაზაზე იყო დამოკიდებული!

პირველი ქაღალდის გამოცემა ჟარგონის ფაილი (Steele-1983) მოიცავდა ასეთი სტრიქონის მაგალითს, რამაც გამოიწვია აღწერილი ხარვეზი, მაგრამ ბეჭდვის შემქმნელმა ის „გამოასწორა“. მას შემდეგ ეს იყო აღწერილი, როგორც "მთვარის ფაზის შეცდომა".

თუმცა, ფრთხილად იყავით ვარაუდებთან. რამდენიმე წლის წინ CERN-ის (ბირთვული კვლევების ევროპული ცენტრის) ინჟინრებს ელექტრონულ-პოზიტრონის დიდ კოლაიდერზე ჩატარებულ ექსპერიმენტებში შეცდომებს წააწყდნენ. იმის გამო, რომ კომპიუტერები აქტიურად ამუშავებენ ამ მოწყობილობის მიერ გამომუშავებულ უზარმაზარ რაოდენობას, სანამ მეცნიერებს შედეგს აჩვენებდნენ, ბევრი ვარაუდობდა, რომ პროგრამა გარკვეულწილად მგრძნობიარე იყო მთვარის ფაზის მიმართ. რამდენიმე სასოწარკვეთილი ინჟინერი სიმართლის ბოლოში ჩაწვდა. შეცდომა წარმოიშვა 27 კმ სიგრძის რგოლის გეომეტრიის უმნიშვნელო ცვლილების გამო მთვარის გავლისას დედამიწის დეფორმაციის გამო! ეს მოთხრობა შევიდა ფიზიკის ფოლკლორში, როგორც „ნიუტონის შურისძიება ნაწილაკების ფიზიკაზე“ და ფიზიკის უმარტივეს და უძველეს კანონებსა და ყველაზე მოწინავე სამეცნიერო ცნებებს შორის კავშირის მაგალითი.

ტუალეტის გამორეცხვა მატარებელს აჩერებს

საუკეთესო ტექნიკის შეცდომა, რომლის შესახებაც ოდესმე მსმენია, იყო საფრანგეთში მაღალსიჩქარიან მატარებელში. შეცდომამ გამოიწვია მატარებლის გადაუდებელი დამუხრუჭება, მაგრამ მხოლოდ იმ შემთხვევაში, თუ ბორტზე მგზავრები იყვნენ. ყოველ ასეთ შემთხვევაში მატარებელი გამოიყვანეს მწყობრიდან, ამოწმებდნენ, მაგრამ ვერაფერი აღმოაჩინეს. შემდეგ ის უკან დააბრუნეს ხაზზე და ის მაშინვე დაეჯახა გაჩერებას.

ერთ-ერთი შემოწმების დროს მატარებლით მოძრავი ინჟინერი ტუალეტში წავიდა. მალევე დაიბანა, ბუმ! გადაუდებელი გაჩერება.

ინჟინერი მძღოლს დაუკავშირდა და ჰკითხა:

- დამუხრუჭებამდე რას აკეთებდი?

-კარგი, დაღმართზე შევანელე...

ეს უცნაური იყო, რადგან ნორმალური მუშაობის დროს მატარებელი ათეულჯერ ანელებს დაღმართზე. მატარებელი დაიძრა და მომდევნო დაღმართზე მძღოლმა გააფრთხილა:

- ვაპირებ შენელებას.

Არაფერი მომხდარა.

- ბოლო დამუხრუჭების დროს რა გააკეთე? - ჰკითხა მძღოლმა.

-კარგი... ტუალეტში ვიყავი...

- კარგი, მაშინ წადი ტუალეტში და რაც გააკეთე, როცა ისევ ჩავალთ!

ინჟინერი წავიდა ტუალეტში და როდესაც მძღოლმა გააფრთხილა: "მე ვანელებ", მან წყალი ჩამოიწურა. რა თქმა უნდა, მატარებელი მაშინვე გაჩერდა.

ახლა მათ შეეძლოთ პრობლემის რეპროდუცირება და მიზეზის პოვნა სჭირდებოდათ.

ორი წუთის შემდეგ შეამჩნიეს, რომ ძრავის სამუხრუჭე დისტანციური მართვის კაბელი (მატარებელს თითო ძრავი ჰქონდა თითოეულ ბოლოში) გათიშული იყო ელექტრული კაბინეტის კედლიდან და იწვა რელეზე, რომელიც აკონტროლებდა ტუალეტის შტეფსელს... როდესაც რელე ჩართული იყო, ის ქმნიდა ჩარევას სამუხრუჭე კაბელში და სისტემის დაცვა შეცდომებისგან უბრალოდ მოიცავდა სასწრაფო დამუხრუჭებას.

კარიბჭე, რომელსაც სძულდა FORTRAN

რამდენიმე თვის წინ ჩვენ შევამჩნიეთ, რომ ქსელური კავშირები მატერიკზე [ეს იყო ჰავაიზე] ძალიან, ძალიან ნელი ხდებოდა. ეს შეიძლება გაგრძელდეს 10-15 წუთის განმავლობაში და შემდეგ მოულოდნელად განმეორდეს. გარკვეული პერიოდის შემდეგ, ჩემმა კოლეგამ დაიჩივლა, რომ ქსელის კავშირები მატერიკზე ზოგადად არ მუშაობს. მას ჰქონდა FORTRAN კოდი, რომელიც საჭირო იყო დაკოპირებულიყო მანქანაში მატერიკზე, მაგრამ ეს ვერ მოხერხდა, რადგან "ქსელი საკმარისად დიდხანს არ ჩერდებოდა FTP ატვირთვის დასასრულებლად".

დიახ, აღმოჩნდა, რომ ქსელის უკმარისობა მოხდა მაშინ, როდესაც კოლეგა ცდილობდა FTP ფაილი FORTRAN-ში წყაროს კოდით გადაეტანა მატერიკზე არსებულ მოწყობილობაზე. ჩვენ შევეცადეთ ფაილის დაარქივება: შემდეგ იგი შეუფერხებლად დაკოპირდა (მაგრამ სამიზნე მანქანას არ ჰქონდა გამხსნელი, ამიტომ პრობლემა არ მოგვარდა). ბოლოს FORTRAN-ის კოდი ძალიან წვრილ ნაწილებად "დავყავით" და სათითაოდ გავგზავნეთ. ფრაგმენტების უმეტესობა დაკოპირდა უპრობლემოდ, მაგრამ რამდენიმე ცალი არ გავიდა ან გავიდა მრავალრიცხოვანი მცდელობები.

როდესაც ჩვენ განვიხილეთ პრობლემური პასაჟები, აღმოვაჩინეთ, რომ მათ ჰქონდათ რაღაც საერთო: ისინი ყველა შეიცავდა კომენტარების ბლოკებს, რომლებიც იწყებოდა და მთავრდებოდა ხაზებით, რომლებიც შედგებოდა დიდი C-ისგან (როგორც კოლეგას ამჯობინა კომენტარი გაეკეთებინა FORTRAN-ში). ჩვენ მივმართეთ ქსელის ექსპერტებს მატერიკზე და ვთხოვეთ დახმარება. რა თქმა უნდა, მათ სურდათ ენახათ ჩვენი ფაილების ნიმუშები, რომელთა გადაცემა FTP-ით ვერ მოხერხდა... მაგრამ ჩვენმა წერილებმა მათ ვერ მიაღწიეს. საბოლოოდ მივიღეთ მარტივი აღწერსროგორ გამოიყურება გადასატანი ფაილები. იმუშავა :) [დავამატო აქ FORTRAN-ის ერთ-ერთი პრობლემური კომენტარის მაგალითი? ალბათ არ ღირს!]

საბოლოოდ მოვახერხეთ ამის გარკვევა. ახლახან დამონტაჟდა ახალი კარიბჭე კამპუსის ჩვენს ნაწილსა და მატერიკულ ქსელს შორის. მას დიდი სირთულე ჰქონდა პაკეტების გადაცემაში, რომლებიც შეიცავდნენ დიდი C-ის განმეორებით ბიტებს! ამ პაკეტებიდან მხოლოდ რამდენიმეს შეუძლია დაიკავოს კარიბჭის ყველა რესურსი და თავიდან აიცილოს სხვა პაკეტების უმეტესობის გავლა. ჩვენ ვუჩივით კარიბჭის მწარმოებელს... და მათ უპასუხეს: ”ოჰ, დიახ, თქვენ წინაშე დგახართ განმეორებითი C-ის შეცდომის წინაშე! ჩვენ უკვე ვიცით მის შესახებ. ” ჩვენ საბოლოოდ გადავწყვიტეთ პრობლემა სხვა მწარმოებლისგან ახალი კარიბჭის შეძენით (პირველის დასაცავად, FORTRAN პროგრამების გადაცემის შეუძლებლობა ზოგიერთისთვის შეიძლება იყოს უპირატესობა!).

რთულია

რამდენიმე წლის წინ, პერლში ETL სისტემის შექმნაზე მუშაობისას, რათა შემემცირებინა 40 ფაზის კლინიკური კვლევების ხარჯები, დამჭირდა დაახლოებით 000 თარიღის დამუშავება. ორმა მათგანმა ტესტი არ ჩააბარა. ეს ძალიან არ მაწუხებდა, რადგან ეს თარიღები აღებულია კლიენტის მიერ მოწოდებული მონაცემებიდან, რაც ხშირად, შეიძლება ითქვას, გასაკვირი იყო. მაგრამ როდესაც გადავამოწმე თავდაპირველი მონაცემები, აღმოჩნდა, რომ ეს თარიღები იყო 1 წლის 2011 იანვარი და 1 წლის 2007 იანვარი. მე მეგონა, რომ შეცდომა შეიცავდა ჩემს მიერ დაწერილ პროგრამაში, მაგრამ აღმოჩნდა, რომ უკვე 30 წელი იყო. ძველი. ეს შეიძლება იდუმალი ჟღერდეს მათთვის, ვინც არ იცნობს პროგრამული ეკოსისტემას. სხვა კომპანიის დიდი ხნის გადაწყვეტილების გამო ფულის შოვნაზე, ჩემმა კლიენტმა გადამიხადა იმ ხარვეზის გამოსწორება, რომელიც ერთმა კომპანიამ შემთხვევით შემოიღო, მეორემ კი განზრახ. იმისათვის, რომ გაიგოთ რაზე ვსაუბრობ, მე უნდა ვისაუბრო კომპანიაზე, რომელმაც დაამატა ფუნქცია, რომელიც საბოლოოდ გახდა შეცდომა, ისევე როგორც რამდენიმე სხვა საინტერესო მოვლენა, რამაც ხელი შეუწყო ჩემს მიერ გამოსწორებულ იდუმალ ხარვეზს.

ძველ კარგ დღეებში Apple-ის კომპიუტერები ზოგჯერ სპონტანურად აღადგენდნენ თარიღს 1 წლის 1904 იანვრამდე. მიზეზი მარტივი იყო: ის იყენებდა ბატარეით მომუშავე „სისტემის საათს“, რათა თვალყური ადევნოდა თარიღსა და დროს. რა მოხდა, როდესაც ბატარეა მოკვდა? კომპიუტერებმა დაიწყეს თარიღის თვალყურის დევნება ეპოქის დასაწყისიდან წამების რაოდენობით. ეპოქაში ჩვენ ვგულისხმობდით საცნობარო თავდაპირველ თარიღს, ხოლო მაკინტოშებისთვის ეს იყო 1 წლის 1904 იანვარი. და ბატარეის მოკვლის შემდეგ, მიმდინარე თარიღი გადაკეთდა მითითებულზე. მაგრამ რატომ მოხდა ეს?

ადრე 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-ის ბევრ აპლიკაციაზე, რომლებსაც ჰქონდათ საკუთარი თარიღის სისტემები შეზღუდვების გვერდის ავლით).

Განაგრძე. ჩვენ გამოვიყენეთ Lotus 1-2-3, IBM-ის „მკვლელი აპლიკაცია“, რომელიც დაეხმარა PC რევოლუციის დაწყებას, თუმცა Apple-ის კომპიუტერებს ჰქონდათ VisiCalc, რამაც პერსონალური კომპიუტერი წარმატებას მიაღწია. სამართლიანობისთვის, 1-2-3 რომ არ გამოჩენილიყო, კომპიუტერები ძნელად აფრინდნენ და პერსონალური კომპიუტერების ისტორია ძალიან განსხვავებულად შეიძლებოდა განვითარებულიყო. Lotus 1-2-3 არასწორად განიხილა 1900 წელი, როგორც ნახტომი წელი. როდესაც მაიკროსოფტმა გამოუშვა თავისი პირველი ცხრილი, Multiplan, მან ბაზრის მცირე წილი დაიპყრო. და როდესაც მათ წამოიწყეს Excel პროექტი, მათ გადაწყვიტეს არა მხოლოდ დააკოპირონ მწკრივების და სვეტების დასახელების სქემა Lotus 1-2-3-დან, არამედ უზრუნველყონ შეცდომების თავსებადობა, 1900 წლის შეგნებულად განხილვით, როგორც ნახტომი წლით. ეს პრობლემა დღესაც არსებობს. ანუ, 1-2-3-ში ეს იყო შეცდომა, მაგრამ Excel-ში ეს იყო შეგნებული გადაწყვეტილება, რომელიც უზრუნველყოფდა, რომ ყველა 1-2-3 მომხმარებელს შეეძლო თავისი ცხრილების იმპორტი Excel-ში მონაცემების შეცვლის გარეშე, თუნდაც ეს არასწორი ყოფილიყო.

მაგრამ იყო სხვა პრობლემა. ჯერ მაიკროსოფტმა გამოუშვა Excel მაკინტოშისთვის, რომელიც არ ცნობდა 1 წლის 1904 იანვრამდე თარიღებს. ხოლო Excel-ში 1 წლის 1900 იანვარი ითვლებოდა ეპოქის დასაწყისად. ამიტომ, დეველოპერებმა შეიტანეს ცვლილება ისე, რომ მათმა პროგრამამ აღიარა ეპოქის ტიპი და შეინახა მონაცემები საკუთარ თავში სასურველი ეპოქის შესაბამისად. Microsoft-მა ამის შესახებ განმარტებითი სტატიაც კი დაწერა. და ამ გადაწყვეტილებამ გამოიწვია ჩემი შეცდომა.

ჩემმა ETL სისტემამ მიიღო Excel-ის ცხრილები მომხმარებლებისგან, რომლებიც შეიქმნა Windows-ზე, მაგრამ ასევე შეიძლება შეიქმნას Mac-ზე. ამრიგად, ცხრილში ეპოქის დასაწყისი შეიძლება იყოს 1 წლის 1900 იანვარი ან 1 წლის 1904 იანვარი. როგორ გავარკვიოთ? Excel ფაილის ფორმატი აჩვენებს საჭირო ინფორმაციას, მაგრამ მე გამოვიყენე პარსერი არ აჩვენებდა (ახლა აჩვენებს) და ვარაუდობთ, რომ თქვენ იცით კონკრეტული ცხრილის ეპოქა. მე ალბათ შემეძლო მეტი დრო დამეხარჯა Excel ორობითი ფორმატის გასაგებად და პაჩის გასაგზავნად პარსერის ავტორს, მაგრამ კიდევ ბევრი რამ მქონდა გასაკეთებელი კლიენტისთვის, ამიტომ სწრაფად დავწერე ევრისტიკა ეპოქის დასადგენად. ის უბრალო იყო.

Excel-ში, 5 წლის 1998 ივლისის თარიღი შეიძლება წარმოდგენილი იყოს ფორმატით "07-05-98" (უსარგებლო ამერიკული სისტემა), "5 ივლისი, 98", "5 ივლისი, 1998", "5-ივლისი-98" ან სხვა ფორმატი, სხვა უსარგებლო ფორმატი (ირონიულად, ერთ-ერთი ფორმატი, რომელიც Excel-ის ჩემს ვერსიას არ გვთავაზობდა, იყო ISO 8601). თუმცა, ცხრილის შიგნით, არაფორმატირებული თარიღი შენახული იყო როგორც "35981" ეპოქისთვის-1900 ან "34519" ეპოქისთვის -1904 (ნომრები წარმოადგენს დღეების რაოდენობას ეპოქის შემდეგ). მე უბრალოდ გამოვიყენე მარტივი პარსერი, რომ გამომეყენებინა წელი ფორმატირებული თარიღიდან, შემდეგ კი გამოვიყენე Excel პარსერი, რომ გამომეყენებინა წელი არაფორმატირებული თარიღიდან. თუ ორივე მნიშვნელობა 4 წლით განსხვავდებოდა, მაშინ ვიცოდი, რომ სისტემას ვიყენებდი ეპოქის 1904-ით.

რატომ არ გამოვიყენე მხოლოდ ფორმატირებული თარიღები? იმის გამო, რომ 5 წლის 1998 ივლისი შეიძლება დაფორმატდეს როგორც "ივლისი, 98" თვის დაკარგული დღით. ჩვენ მივიღეთ ცხრილები იმდენი კომპანიისგან, რომლებმაც შექმნეს ისინი სხვადასხვა გზით, რომ ჩვენზე იყო (ამ შემთხვევაში, მე) თარიღების გარკვევა. გარდა ამისა, თუ Excel-მა სწორად გაიგო, მაშინ ჩვენც ასე უნდა ვიყოთ!

პარალელურად შემხვდა 39082. შეგახსენებთ, რომ Lotus 1-2-3 1900 წელი ნახტომად მიიჩნია და ეს ერთგულად განმეორდა Excel-ში. და რადგან ამან ერთი დღე დაამატა 1900 წელს, თარიღის გამოთვლის მრავალი ფუნქცია შეიძლება არასწორი იყოს სწორედ იმ დღეს. ანუ, 39082 შეიძლებოდა ყოფილიყო 1 წლის 2011 იანვარი (Mac-ებზე) ან 31 წლის 2006 დეკემბერი (Windows-ზე). თუ ჩემმა „წლის პარსერმა“ ამოიღო 2011 წელი ფორმატირებული მნიშვნელობიდან, მაშინ ყველაფერი კარგადაა. მაგრამ რადგან Excel-ის პარსერმა არ იცის რა ეპოქის გამოყენება ხდება, ის ნაგულისხმევად ადგენს epoch-1900-ს და აბრუნებს 2006 წელს. ჩემმა აპლიკაციამ დაინახა, რომ განსხვავება იყო 5 წელი, ჩათვალა შეცდომად, ჩაწერა და დააბრუნა არაფორმატირებული მნიშვნელობა.

ამის გადასაჭრელად მე დავწერე ეს (ფსევდოკოდი):

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-ში, ახლა უკვე გაუქმებულ განყოფილებაში, რომელიც ქმნიდა ფირის დისკებს და პნევმატურ სისტემებს მაღალსიჩქარიანი ლენტის კვებისათვის.

მათ გადააკეთეს დისკები ისე, რომ მათ შეეძლოთ ჰქონოდათ ერთი ცენტრალური "A" დისკი დაკავშირებული შვიდ "B" დისკთან და RAM-ის პატარა OS, რომელიც აკონტროლებდა "A" დისკს, შეეძლო წაკითხვის და ჩაწერის ოპერაციების დელეგირება ყველა "B" დისკზე.

ყოველ ჯერზე, როდესაც დისკი "A" იწყებოდა, საჭირო იყო დისკის ჩასმა "A"-სთან დაკავშირებულ პერიფერიულ დისკში, რათა ოპერაციული სისტემა მის მეხსიერებაში ჩასატვირთა. ეს იყო უკიდურესად პრიმიტიული: გამოთვლითი სიმძლავრე უზრუნველყოფილი იყო 8-ბიტიანი მიკროკონტროლით.

ასეთი აღჭურვილობის სამიზნე აუდიტორია იყო კომპანიები, რომლებსაც აქვთ მონაცემთა ძალიან დიდი საწყობი - ბანკები, საცალო ქსელები და ა.

ერთ კლიენტს პრობლემა ჰქონდა. ბეჭდვის სამუშაოს შუაში, ერთმა კონკრეტულმა დისკმა "A" შეიძლება შეწყვიტოს მუშაობა, რაც გამოიწვევს მთელი სამუშაოს შეჩერებას. დისკის მუშაობის აღსადგენად, პერსონალს მოუწია ყველაფრის გადატვირთვა. და თუ ეს მოხდა ექვსსაათიანი დავალების შუა რიცხვებში, მაშინ დაიკარგა უზარმაზარი ძვირადღირებული კომპიუტერული დრო და ჩაიშალა მთელი ოპერაციის განრიგი.

ტექნიკოსები გაგზავნეს Storage Technologies-დან. მაგრამ, მიუხედავად მათი საუკეთესო ძალისხმევისა, მათ ვერ შეძლეს შეცდომის რეპროდუცირება ტესტის პირობებში: როგორც ჩანს, ეს მოხდა დიდი ბეჭდვითი სამუშაოების შუაში. პრობლემა არ იყო აპარატურა, მათ შეცვალეს ყველაფერი, რაც შეეძლოთ: ოპერატიული მეხსიერება, მიკროკონტროლერი, ფლოპი დრაივი, ფირის დისკის ყველა შესაძლო ნაწილი - პრობლემა შენარჩუნდა.

შემდეგ ტექნიკოსებმა დარეკეს შტაბში და გამოიძახეს ექსპერტი.

ექსპერტმა აიღო სკამი და ფინჯანი ყავა, დაჯდა კომპიუტერის ოთახში - იმ დღეებში იყო კომპიუტერებისთვის განკუთვნილი ოთახები - და უყურებდა, როგორ დგას პერსონალი დიდი ბეჭდვის სამუშაოს რიგში. ექსპერტი ელოდა წარუმატებლობას - და ასეც მოხდა. ყველამ შეხედა ექსპერტს, მაგრამ მას წარმოდგენა არ ჰქონდა, რატომ მოხდა ეს. ასე რომ, მან ბრძანა, რომ სამუშაო კვლავ რიგში დადგა და ყველა თანამშრომელი და ტექნიკოსი დაუბრუნდა სამუშაოს.

ექსპერტი ისევ სავარძელში ჩაჯდა და წარუმატებლობის ლოდინი დაიწყო. გავიდა დაახლოებით ექვსი საათი და მარცხი მოხდა. ექსპერტს კვლავ წარმოდგენა არ ჰქონდა, გარდა იმისა, რომ ყველაფერი ხალხით სავსე ოთახში ხდებოდა. მან ბრძანა მისიის ხელახლა დაწყება, დაჯდა და დაელოდა.

მესამე წარუმატებლობისას ექსპერტმა რაღაც შენიშნა. მარცხი მოხდა მაშინ, როდესაც პერსონალმა შეცვალა ფირები უცხოურ დისკზე. უფრო მეტიც, მარცხი მაშინვე მოხდა, როდესაც ერთ-ერთმა თანამშრომელმა იატაკზე გარკვეული ფილა გაიარა.

აწეული იატაკი 6-დან 8 ინჩის სიმაღლეზე დაგებული ალუმინის ფილებით იყო დამზადებული. აწეული იატაკის ქვეშ კომპიუტერებიდან მრავალი მავთული გადიოდა, რათა ვინმემ შემთხვევით არ გადააბიჯა მნიშვნელოვან კაბელს. ფილები ძალიან მჭიდროდ იყო დაგებული, რათა ნამსხვრევები არ მოხვედრილიყო აწეული იატაკის ქვეშ.

ექსპერტი მიხვდა, რომ ერთ-ერთი ფილა დეფორმირებული იყო. როდესაც თანამშრომელი მის კუთხეს დააბიჯებდა, კრამიტის კიდეები მეზობელ ფილებს შეეჯახა. პლასტმასის ნაწილები, რომლებიც აკავშირებდა ფილებს, ასევე იწურებოდა მათთან, რამაც გამოიწვია სტატიკური მიკროგამონადენი, რამაც გამოიწვია რადიოსიხშირული ჩარევა.

დღეს RAM ბევრად უკეთ არის დაცული რადიოსიხშირული ჩარევისგან. მაგრამ იმ წლებში ეს ასე არ იყო. ექსპერტმა გააცნობიერა, რომ ეს ჩარევა არღვევდა მეხსიერებას და მასთან ერთად ოპერაციული სისტემის მუშაობას. დარეკა დამხმარე სამსახურში, შეუკვეთა ახალი ფილები, თვითონ დაამონტაჟა და პრობლემაც გაქრა.

მოქცევაა!

ამბავი მოხდა სერვერის ოთახში, პორტსმუთის ოფისის მეოთხე ან მეხუთე სართულზე (ვფიქრობ), დოკების ზონაში.

ერთ მშვენიერ დღეს Unix სერვერი ძირითადი მონაცემთა ბაზისით გაფუჭდა. მათ გადატვირთეს, მაგრამ ის სიხარულით განაგრძობდა ისევ და ისევ დაცემას. გადავწყვიტეთ დარეკვა დამხმარე სერვისიდან.

დამხმარე ბიჭი... მგონი მარკ ერქვა, მაგრამ ამას არ აქვს მნიშვნელობა... მგონი არ ვიცნობ. არ აქვს მნიშვნელობა, ნამდვილად. მოდით, მარკს დავრჩეთ, კარგი? დიდი.

ასე რომ, რამდენიმე საათის შემდეგ მარკი ჩამოვიდა (ლიდსიდან პორტსმუთამდე დიდი გზა არ არის, თქვენ იცით), ჩართო სერვერი და ყველაფერი უპრობლემოდ მუშაობდა. ტიპიური წყეული მხარდაჭერა, კლიენტი ძალიან აღელვებს ამის გამო. მარკი ათვალიერებს ჟურნალის ფაილებს და უსუსურს ვერაფერს აღმოაჩენს. მარკი დაბრუნდა მატარებელში (ან ტრანსპორტის რომელი მეთოდითაც ჩამოვიდა, ეს შეიძლებოდა კოჭლი ძროხა ყოფილიყო, რა ვიცი... მაინც, არ აქვს მნიშვნელობა, კარგი?) და ფუჭად უბრუნდება ლიდსში. დღე.

იმავე საღამოს სერვერი ისევ ავარია. ამბავი იგივეა... სერვერი არ ამოდის. მარკი ცდილობს დისტანციურად დახმარებას, მაგრამ კლიენტი ვერ ახერხებს სერვერის გაშვებას.

კიდევ ერთი მატარებელი, ავტობუსი, ლიმონის მერინგი ან სხვა სისულელე და მარკი დაბრუნდა პორტსმუთში. შეხედე, სერვერი უპრობლემოდ იტვირთება! სასწაული. მარკი რამდენიმე საათს ატარებს იმის შემოწმებას, რომ ყველაფერი წესრიგშია ოპერაციულ სისტემასთან ან პროგრამულ უზრუნველყოფასთან და გაემგზავრება ლიდსში.

დაახლოებით დღის შუა რიცხვებში სერვერი იშლება (დამშვიდდით!). ამჯერად გონივრულია სერვერის შესაცვლელად ტექნიკის მხარდაჭერის ხალხის შემოყვანა. მაგრამ არა, დაახლოებით 10 საათის შემდეგ ისიც ეცემა.

სიტუაცია რამდენიმე დღის განმავლობაში განმეორდა. სერვერი მუშაობს, იშლება დაახლოებით 10 საათის შემდეგ და არ იწყება მომდევნო 2 საათის განმავლობაში. შეამოწმეს გაგრილება, მეხსიერების გაჟონვა, შეამოწმეს ყველაფერი, მაგრამ ვერაფერი იპოვეს. შემდეგ ავარიები შეწყდა.

კვირამ უდარდელად ჩაიარა... ყველა ბედნიერი იყო. ბედნიერი სანამ ყველაფერი თავიდან არ დაიწყება. სურათი იგივეა. 10 საათი მუშაობა, 2-3 საათი დასვენება...

და შემდეგ ვიღაცამ (მგონი მათ მითხრეს, რომ ამ ადამიანს არანაირი კავშირი არ ჰქონდა IT-თან) თქვა:

"მოქცევაა!"

ძახილს ცარიელი მზერა მოჰყვა და ვიღაცის ხელი ალბათ ყოყმანობდა უსაფრთხოების ზარის ღილაკზე.

”ის წყვეტს მუშაობას ტალღასთან ერთად.”

როგორც ჩანს, ეს სრულიად უცხო კონცეფციაა IT მხარდაჭერის მუშაკებისთვის, რომლებიც ნაკლებად სავარაუდოა, რომ წაიკითხონ Tide Yearbook-ი ყავის დასალევად ჯდომისას. მათ განმარტეს, რომ ეს არანაირად არ შეიძლება იყოს დაკავშირებული მოქცევასთან, რადგან სერვერი ერთი კვირის განმავლობაში მუშაობდა წარუმატებლად.

"გასულ კვირას ტალღა დაბალი იყო, მაგრამ ამ კვირაში მაღალია."

მცირე ტერმინოლოგია მათთვის, ვისაც არ აქვს იახტის ლიცენზია. მოქცევა დამოკიდებულია მთვარის ციკლზე. და როდესაც დედამიწა ბრუნავს, ყოველ 12,5 საათში მზისა და მთვარის გრავიტაციული ძალა ქმნის მოქცევის ტალღას. 12,5-საათიანი ციკლის დასაწყისში არის მოქცევა, შუა ციკლის მოქცევა, ბოლოს კი ისევ მოქცევა. მაგრამ როგორც მთვარის ორბიტა იცვლება, ასევე იცვლება განსხვავება დაბალ და მაღალ მოქცევას შორის. როდესაც მთვარე იმყოფება მზესა და დედამიწას შორის ან დედამიწის მოპირდაპირე მხარეს (სრული მთვარე ან მთვარე არ არის), ჩვენ ვიღებთ Syzygyn ტალღებს - ყველაზე მაღალ ტალღებს და ყველაზე დაბალ მოქცევას. ნახევარმთვარეზე ვიღებთ კვადრატულ მოქცევას - ყველაზე დაბალ მოქცევას. განსხვავება ორ უკიდურესობას შორის მნიშვნელოვნად მცირდება. მთვარის ციკლი გრძელდება 28 დღე: სიზიგიური - კვადრატურა - სიზიგიური - კვადრატურა.

როდესაც ტექნიკოსებს აუხსნეს მოქცევის ძალების არსი, მათ მაშინვე ჩათვალეს, რომ პოლიციის გამოძახება სჭირდებოდათ. და საკმაოდ ლოგიკურიც. მაგრამ აღმოჩნდა, რომ ძმაკაცი მართალი იყო. ორი კვირით ადრე, გამანადგურებელი ოფისიდან არც თუ ისე შორს დადგა. ყოველ ჯერზე, როცა მოქცევა აწევდა მას გარკვეულ სიმაღლეზე, გემის სარადარო პოსტი მთავრდებოდა სერვერის ოთახის იატაკის დონეზე. და რადარმა (ან ელექტრონული ომის აღჭურვილობა, ან სხვა სამხედრო სათამაშო) შექმნა ქაოსი კომპიუტერებში.

ფრენის მისია რაკეტისთვის

მე დავალებული მქონდა დიდი (დაახლოებით 400 ათასი ხაზი) ​​რაკეტების გაშვების კონტროლისა და მონიტორინგის სისტემის პორტირება ოპერაციული სისტემის, შემდგენელისა და ენის ახალ ვერსიებზე. უფრო ზუსტად, Solaris 2.5.1-დან Solaris 7-მდე და Verdix Ada Development System-დან (VADS), დაწერილი Ada 83-ში, Rational Apex Ada სისტემამდე, დაწერილი Ada 95-ში. VADS შეიძინა Rational-მა და მისი პროდუქტი იყო. მოძველებული, თუმცა Rational ცდილობდა დაენერგა VADS-სპეციფიკური პაკეტების თავსებადი ვერსიები Apex-ის შემდგენელზე გადასვლის გასაადვილებლად.

სამი ადამიანი დამეხმარა უბრალოდ კოდის სუფთად შედგენაში. ორი კვირა დასჭირდა. შემდეგ კი მე თვითონ ვიმუშავე, რომ სისტემა იმუშაოს. მოკლედ, ეს იყო ყველაზე ცუდი არქიტექტურა და პროგრამული სისტემის დანერგვა, რაც მე შემხვედრია, ამიტომ პორტის დასრულებას კიდევ ორი ​​თვე დასჭირდა. შემდეგ სისტემა გადაეცა ტესტირებას, რასაც კიდევ რამდენიმე თვე დასჭირდა. მე მაშინვე გამოვასწორე შეცდომები, რომლებიც აღმოჩენილი იქნა ტესტირების დროს, მაგრამ მათი რიცხვი სწრაფად შემცირდა (საწყისი კოდი წარმოების სისტემა იყო, ამიტომ მისი ფუნქციონირება საკმაოდ საიმედოდ მუშაობდა, უბრალოდ მომიწია შეცდომების ამოღება, რომლებიც წარმოიშვა ახალ შემდგენელთან ადაპტაციის დროს). საბოლოოდ, როცა ყველაფერი ისე მუშაობდა, როგორც უნდა, სხვა პროექტში გადამიყვანეს.

და მადლიერების წინა პარასკევს ტელეფონმა დარეკა.

რაკეტის გაშვება დაახლოებით სამ კვირაში უნდა შემოწმდეს და ათვლის ლაბორატორიული ტესტების დროს ბრძანებების თანმიმდევრობა დაიბლოკა. რეალურ ცხოვრებაში, ეს შეწყვეტს ტესტირებას და თუ ბლოკირება მოხდება ძრავის ამოქმედებიდან რამდენიმე წამში, დამხმარე სისტემებში მოხდება რამდენიმე შეუქცევადი მოქმედება, რაც მოითხოვს რაკეტის ხანგრძლივი და ძვირადღირებული მზადყოფნას. ეს არ დაიწყებოდა, მაგრამ ბევრი ადამიანი ძალიან განაწყენებული იქნებოდა დროის დაკარგვაზე და ბევრი, ბევრი ფულის გამო. არავის მისცეთ უფლება გითხრათ, რომ თავდაცვის დეპარტამენტი ფულს უგუნურად ხარჯავს - მე არასოდეს შემხვედრია კონტრაქტის მენეჯერი, რომელიც ბიუჯეტის პირველ და მეორე ნაწილს არ აყენებს, რასაც მოჰყვება გრაფიკი.

წინა თვეებში, ეს გამოწვევა ასობით ჯერ განხორციელდა მრავალი ვარიაციით, მხოლოდ რამდენიმე მცირე სლოკინით. ასე რომ, ამის ალბათობა ძალიან დაბალი იყო, მაგრამ მისი შედეგები ძალიან მნიშვნელოვანი იყო. გაამრავლეთ ორივე ეს ფაქტორი და მიხვდებით, რომ სიახლეები მე და ათეულობით ინჟინერსა და მენეჯერს დანგრეული სადღესასწაულო კვირა უწინასწარმეტყველეს.

და ყურადღება მიაქციეს მე, როგორც სისტემის პორტირებას.

როგორც უსაფრთხოებისთვის კრიტიკული სისტემების უმეტესობის შემთხვევაში, ბევრი პარამეტრი იყო ჩაწერილი, ამიტომ საკმაოდ მარტივი იყო კოდის რამდენიმე ხაზის იდენტიფიცირება, რომლებიც შესრულდა სისტემის ავარიამდე. და რა თქმა უნდა, მათში აბსოლუტურად არაფერი იყო უჩვეულო; ერთი და იგივე გამონათქვამები წარმატებით იქნა შესრულებული სიტყვასიტყვით ათასობით ჯერ ერთი და იგივე რბენის დროს.

ჩვენ გამოვიძახეთ ხალხი Apex-დან Rational-ში, რადგან ისინი იყვნენ ვინც შეიმუშავეს შემდგენელი და მათ მიერ შემუშავებული ზოგიერთი რუტინა გამოიძახეს საეჭვო კოდში. მათ (და ყველას) შთაბეჭდილება მოახდინა, რომ საჭირო იყო ფაქტიურად ეროვნული მნიშვნელობის პრობლემის სათავეში ჩასვლა.

ვინაიდან ჟურნალებში არაფერი იყო საინტერესო, გადავწყვიტეთ პრობლემის რეპროდუცირება ადგილობრივ ლაბორატორიაში. ეს არ იყო ადვილი ამოცანა, რადგან ღონისძიება დაახლოებით 1000 გაშვებაზე ერთხელ ხდებოდა. ერთი საეჭვო მიზეზი იყო ზარი გამყიდველის მიერ შემუშავებული mutex ფუნქციაზე (VADS მიგრაციის პაკეტის ნაწილი) Unlock არ გამოიწვია განბლოკვა. დამუშავების ძაფი, რომელიც ფუნქციას ეძახდა, ამუშავებდა გულისცემის შეტყობინებებს, რომლებიც ნომინალურად ყოველ წამს მოდიოდა. სიხშირე ავწიეთ 10 ჰც-მდე, ანუ წამში 10-ჯერ და დავიწყეთ სირბილი. დაახლოებით ერთი საათის შემდეგ სისტემა თავისთავად დაიბლოკა. ჟურნალში ვნახეთ, რომ ჩაწერილი შეტყობინებების თანმიმდევრობა იგივე იყო, რაც წარუმატებელი ტესტის დროს. ჩვენ გავაკეთეთ კიდევ რამდენიმე გაშვება, სისტემა მუდმივად იბლოკებოდა დაწყებიდან 45-90 წუთის შემდეგ და ყოველ ჯერზე ჟურნალი შეიცავდა ერთსა და იმავე მარშრუტს. მიუხედავად იმისა, რომ ჩვენ ტექნიკურად ვატარებდით სხვადასხვა კოდს - შეტყობინების სიხშირე განსხვავებული იყო - სისტემის ქცევა იგივე იყო, ამიტომ ჩვენ დარწმუნებული ვიყავით, რომ დატვირთვის ეს სცენარი იგივე პრობლემას იწვევდა.

ახლა ჩვენ უნდა გაერკვია, სად მოხდა ზუსტად დაბლოკვა გამონათქვამების თანმიმდევრობით.

სისტემის ამ დანერგვამ გამოიყენა ადა ამოცანების სისტემა და გამოიყენა ის წარმოუდგენლად ცუდად. Tasks არის მაღალი დონის პარალელურად შესრულებადი კონსტრუქცია Ada-ში, რაღაც აღსრულების ძაფების მსგავსი, ჩაშენებული მხოლოდ თავად ენაში. როდესაც ორ ამოცანას სჭირდება კომუნიკაცია, ისინი „აწყობენ პაემანს“, გაცვლიან საჭირო მონაცემებს და შემდეგ წყვეტენ პაემანს და უბრუნდებიან დამოუკიდებელ აღსრულებას. თუმცა, სისტემა სხვაგვარად იქნა დანერგილი. მას შემდეგ, რაც სამიზნე დავალება იყო პაემანი, ეს სამიზნე ამოცანა შეხვედროდა სხვა ამოცანას, რომელიც შემდეგ შეხვედროდა მესამე ამოცანას და ასე შემდეგ, სანამ გარკვეული დამუშავება არ დასრულებულა. ამის შემდეგ, ყველა ეს პაემანი დასრულდა და თითოეული დავალება უნდა დაბრუნებულიყო მის შესრულებას. ანუ, საქმე გვქონდა მსოფლიოში ყველაზე ძვირადღირებულ ფუნქციის გამოძახების სისტემასთან, რომელმაც შეაჩერა მთელი „მრავალდავალებების“ პროცესი, როდესაც ამუშავებდა შეყვანის მონაცემების ნაწილს. და მანამდე ეს არ იწვევდა პრობლემებს მხოლოდ იმიტომ, რომ გამტარუნარიანობა იყო ძალიან დაბალი.

მე აღვწერე დავალების ეს მექანიზმი, რადგან როდესაც პაემანი მოითხოვეს ან მოსალოდნელი იყო დასრულებულიყო, შეიძლება მოხდეს "დავალებების შეცვლა". ანუ, პროცესორს შეუძლია დაიწყოს სხვა ამოცანის დამუშავება, რომელიც მზად არის შესასრულებლად. გამოდის, რომ როდესაც ერთი დავალება მზად არის მეორე დავალებასთან შესახვედრად, სრულიად განსხვავებული დავალების შესრულება შეიძლება დაიწყოს და საბოლოოდ კონტროლი უბრუნდება პირველ პაემანს. და შეიძლება მოხდეს სხვა მოვლენები, რომლებიც იწვევს ამოცანის შეცვლას; ერთ-ერთი ასეთი მოვლენაა გამოძახება სისტემის ფუნქციაზე, როგორიცაა მუტექსის დაბეჭდვა ან შესრულება.

იმის გასაგებად, თუ რომელი კოდის ხაზი იწვევდა პრობლემას, მე უნდა მეპოვა გზა, რომ ჩამეწერა პროგრესი განცხადებების თანმიმდევრობით, ამოცანის ამომრთველის გააქტიურების გარეშე, რაც თავიდან აიცილებდა ავარიას. ასე რომ, მე ვერ ვისარგებლე Put_Line()I/O ოპერაციების შესრულების თავიდან ასაცილებლად. მე შემიძლია დავაყენო მრიცხველის ცვლადი ან მსგავსი რამ, მაგრამ როგორ ვნახო მისი მნიშვნელობა, თუ არ შემიძლია მისი ჩვენება ეკრანზე?

ასევე, ჟურნალის შემოწმებისას, აღმოჩნდა, რომ გულისცემის შეტყობინებების დამუშავების გაყინვის მიუხედავად, რამაც დაბლოკა პროცესის ყველა I/O ოპერაცია და ხელი შეუშალა სხვა დამუშავების შესრულებას, სხვა დამოუკიდებელი ამოცანების შესრულება გაგრძელდა. ანუ, სამუშაო არ იყო მთლიანად დაბლოკილი, მხოლოდ (კრიტიკული) დავალებების ჯაჭვი.

ეს იყო მინიშნება, რომელიც საჭირო იყო ბლოკირების გამოხატვის შესაფასებლად.

მე გავაკეთე Ada პაკეტი, რომელიც შეიცავდა ამოცანას, ჩამოთვლილ ტიპს და ამ ტიპის გლობალურ ცვლადს. რიცხობრივი ლიტერალები დაკავშირებული იყო პრობლემური თანმიმდევრობის კონკრეტულ გამონათქვამებთან (მაგ. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), და შემდეგ ჩასვით მასში დავალების გამონათქვამები, რომლებიც ანიჭებენ შესაბამის ჩამოთვლას გლობალურ ცვლადს. ვინაიდან ამ ყველაფრის ობიექტის კოდი უბრალოდ ინახავდა მეხსიერებაში მუდმივობას, მისი შესრულების შედეგად ამოცანის გადართვა უკიდურესად საეჭვო იყო. ჩვენ, უპირველეს ყოვლისა, საეჭვო ვიყავით გამონათქვამებში, რომლებსაც შეეძლოთ დავალების შეცვლა, რადგან დაბლოკვა მოხდა შესრულებისას და არა დაბრუნების დროს, როდესაც დავალება გადართეთ (რამდენიმე მიზეზის გამო).

თვალთვალის დავალება უბრალოდ გადიოდა ციკლში და პერიოდულად ამოწმებდა, შეიცვალა თუ არა გლობალური ცვლადის მნიშვნელობა. ყოველი ცვლილებისას, მნიშვნელობა შენახული იყო ფაილში. შემდეგ მოკლე ლოდინი და ახალი შემოწმება. მე დავწერე ცვლადი ფაილში, რადგან დავალება შესრულდა მხოლოდ მაშინ, როდესაც სისტემამ აირჩია იგი შესასრულებლად პრობლემის არეალში ამოცანის გადართვისას. რაც არ უნდა მომხდარიყო ამ ამოცანაში, არ იმოქმედებს სხვა, დაუკავშირებელ დაბლოკილ ამოცანებზე.

მოსალოდნელი იყო, რომ როდესაც სისტემა მიაღწევდა პრობლემური კოდის შესრულების წერტილს, გლობალური ცვლადი გადატვირთული იქნებოდა ყოველ მომდევნო გამოსახულებაზე გადასვლისას. შემდეგ მოხდება ისეთი რამ, რაც იწვევს ამოცანის შეცვლას და რადგან მისი შესრულების სიხშირე (10 ჰც) უფრო დაბალია, ვიდრე მონიტორინგის დავალება, მონიტორს შეუძლია გლობალური ცვლადის მნიშვნელობა დაიჭიროს და დაწეროს იგი. ნორმალურ ვითარებაში მე შემეძლო მიმეღო ჩამოთვლების ქვეჯგუფის განმეორებითი თანმიმდევრობა: ცვლადის ბოლო მნიშვნელობები დავალების გადართვის დროს. ჩამოკიდებისას გლობალური ცვლადი აღარ უნდა შეიცვალოს და ბოლო დაწერილი მნიშვნელობა მიუთითებს, რომელი გამოთქმა არ დასრულებულა.

მე გავუშვი კოდი თვალთვალის საშუალებით. გაიყინა. და მონიტორინგი საათის მექანიზმად მუშაობდა.

ჟურნალი შეიცავდა მოსალოდნელ თანმიმდევრობას, რომელიც შეწყვეტილი იყო მნიშვნელობით, რომელიც მიუთითებს, რომ გამოძახებული იყო მუტექსი Unlock, და დავალება არ არის დასრულებული - როგორც ეს არის ათასობით წინა ზარის შემთხვევაში.

Apex-ის ინჟინრები ამ დროს ციებ-ცხელებით აანალიზებდნენ მათ კოდს და იპოვეს ადგილი მუტექსში, სადაც, თეორიულად, საკეტი შეიძლებოდა მომხდარიყო. მაგრამ მისი ალბათობა ძალიან დაბალი იყო, რადგან გარკვეულ დროს მომხდარი მოვლენების მხოლოდ გარკვეული თანმიმდევრობა შეიძლება გამოიწვიოს დაბლოკვა. მერფის კანონი, ბიჭებო, ეს მერფის კანონია.

კოდის ნაწილის დასაცავად, რომელიც მე მჭირდებოდა, მე შევცვალე mutex ფუნქციის ზარები (აშენებული OS mutex ფუნქციონალობის თავზე) პატარა მშობლიური Ada mutex პაკეტით, რათა მეკონტროლებინა mutex წვდომა ამ ნაწილზე.

კოდში ჩავდე და ტესტი ჩავაბარე. შვიდი საათის შემდეგ კოდი კვლავ მუშაობდა.

ჩემი კოდი გადაეგზავნა Rational-ს, სადაც შეადგინეს, დაშალეს და შეამოწმეს, რომ არ იყენებდა იგივე მიდგომას, რაც გამოიყენებოდა პრობლემურ mutex ფუნქციებში.

ეს იყო ყველაზე ხალხმრავალი კოდის მიმოხილვა ჩემს კარიერაში 🙂 ჩემთან ერთად ოთახში ათი ინჟინერი და მენეჯერი იყო, კიდევ ათი ადამიანი იყო საკონფერენციო ზარზე - და ყველამ შეისწავლა კოდის დაახლოებით 20 ხაზი.

კოდი განიხილეს, შეიკრიბა ახალი შესრულებადი ფაილები და წარადგინეს ფორმალური რეგრესიის ტესტირებისთვის. ორიოდე კვირის შემდეგ უკუნთვლა ტესტი წარმატებით დასრულდა და რაკეტა აფრინდა.

კარგი, ეს ყველაფერი კარგია, მაგრამ რა აზრი აქვს ამ ამბავს?

ეს იყო აბსოლუტურად ამაზრზენი პრობლემა. ასიათასობით კოდის ხაზი, პარალელური შესრულება, ათზე მეტი ურთიერთდაკავშირებული პროცესი, ცუდი არქიტექტურა და ცუდი განხორციელება, ინტერფეისები ჩაშენებული სისტემებისთვის და დახარჯული მილიონობით დოლარი. არანაირი ზეწოლა, არა.

ამ პრობლემაზე მარტო მე არ ვმუშაობდი, თუმცა პორტირების დროს ყურადღების ცენტრში ვიყავი. მაგრამ მიუხედავად იმისა, რომ მე ეს გავაკეთე, ეს არ ნიშნავს რომ მე მესმოდა კოდის ასიათასობით სტრიქონი, ან თუნდაც გადავხედე მათ. კოდი და ჟურნალი გაანალიზებული იქნა ინჟინრების მიერ მთელი ქვეყნის მასშტაბით, მაგრამ როდესაც მათ მითხრეს თავიანთი ჰიპოთეზები წარუმატებლობის მიზეზების შესახებ, მხოლოდ ნახევარი წუთი დამჭირდა მათ უარსაყოფად. და როცა მთხოვდნენ თეორიების გაანალიზებას, ამას სხვას გადავცემდი, რადგან ჩემთვის აშკარა იყო, რომ ეს ინჟინრები არასწორ გზას მიდიოდნენ. თავხედურად ჟღერს? დიახ, ეს მართალია, მაგრამ მე სხვა მიზეზით უარვყავი ჰიპოთეზები და მოთხოვნები.

მე მესმოდა პრობლემის ბუნება. ზუსტად არ ვიცოდი სად ხდებოდა ან რატომ, მაგრამ ვიცოდი რა ხდებოდა.

წლების განმავლობაში დამიგროვდა დიდი ცოდნა და გამოცდილება. მე ვიყავი ადას გამოყენების ერთ-ერთი პიონერი და გავიგე მისი დადებითი და უარყოფითი მხარეები. მე ვიცი, როგორ უმკლავდება Ada Runtime ბიბლიოთეკები ამოცანებს და როგორ უმკლავდება პარალელურად შესრულებას. მე მესმის დაბალი დონის პროგრამირება მეხსიერების, რეგისტრების და ასამბლერის დონეზე. სხვა სიტყვებით რომ ვთქვათ, მე მაქვს ღრმა ცოდნა ჩემს სფეროში. და გამოვიყენე ისინი პრობლემის მიზეზის მოსაძებნად. მე არ ვმუშაობდი მხოლოდ შეცდომის გარშემო, მე მესმოდა, თუ როგორ უნდა ვიპოვო ის ძალიან მგრძნობიარე გაშვების გარემოში.

კოდებთან ბრძოლის ასეთი ისტორიები არც თუ ისე საინტერესოა მათთვის, ვინც არ იცნობს ასეთი ბრძოლის თავისებურებებსა და პირობებს. მაგრამ ეს ისტორიები გვეხმარება გავიგოთ, რა არის საჭირო მართლაც რთული პრობლემების გადასაჭრელად.

მართლაც რთული პრობლემების გადასაჭრელად, თქვენ უნდა იყოთ უფრო მეტი, ვიდრე უბრალოდ პროგრამისტი. თქვენ უნდა გესმოდეთ კოდის „ბედი“, როგორ ურთიერთქმედებს ის გარემოსთან და როგორ მუშაობს თავად გარემო.

შემდეგ კი გექნებათ საკუთარი დანგრეული სადღესასწაულო კვირა.

გაგრძელდება.

წყარო: www.habr.com