ავტომატიზაციის პლატფორმის შეცვლა პროცესის დაკარგვის გარეშე

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

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

რას აჩენს ოთხი წყარო

Fairwinds-ის 16 ოქტომბრის მასალა CNCF-ზე n8n-ის Helm-ჩარტებს შორის გადასვლას აღწერს მუდმივი კომპონენტების შენარჩუნებით. ეს ავტორის გამოცდილებაა და არა ყველა გარემოსთვის სავალდებულო ნიმუში.

Workato-ს 14 ოქტომბრის განხილვა შექმნასა და შეძენას ადარებს. GitLab-ის 13 ოქტომბრის განცხადება განვითარების ეტაპებს შორის კოორდინაციას ეხება. Azure-ის 8 ოქტომბრის მასალა დაგეგმვას გამძლე შესრულებისგან გამოყოფს.

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

რა გადაგვაქვს

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

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

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

პირობითი მაგალითი: მომსახურების განაცხადები

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

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

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

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

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

პასუხისმგებლობის ფასი

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

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

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