რატომ წარმოიქმნება წარმადობის პრობლემა?

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

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

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

პირველი ეტაპი - გადაბრალება

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

მეორე ეტაპი - მკითხაობა

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

მესამე ეტაპი - ანალიზი

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

1C პლატფორმის შეზღუდვები

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

მაგრამ 8.1-ისა და მომდენო ვერსიების გამოსვლის შემდეგ სიტუაცია სრულიად შეიცვალა. გამოჩნდა მაშტაბირების შესაძლებლობა, მონაცემთა ბლოკირების მართვის რეჟიმი, დროებითი ცხრილები, შეიცვალა ცხრილების სტრუქტურა მომხმარებელთა პარალელური მუშაობისათვის და სხვა მრავალი სიახლე. მოცემული მომენტისათვის შესაძლებელია, რომ ათასობით მომხმარებლიანმა 1C-ის ბაზამ იმუშაობს 24/7-ზე.

ყველა ეს გაუმჯობესებული ფუნქციონალი საშუალებას იძლევა აიწყოს ინფორმაციული სისტემა 1C-ის ბაზაზე თითქმის ყველა მაშტაბისათვის.

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

შემმუშავებლები ჩამორჩებიან პლატფორმის განვითარებას

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

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

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

ჭირი იქა, ლხინი აქა, ქატო იქა, ფქვილი არა J