რატომ სჭირდება რამდენიმე დღე დაგზავნის სიიდან გამოწერის გაუქმებას?

ერთ-ერთმა ტვიტერმა იკითხა, რატომ შეიძლება გამოწერის გაუქმებას „დღეები დასჭირდეს“. ბალთა მჭიდროდ, მე ვაპირებ გითხრათ წარმოუდგენელი ისტორია იმის შესახებ, თუ როგორ კეთდება ეს Enterprise Development™-ში...

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

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

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

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

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

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

საფოსტო ჯგუფში წერილებს ამოწმებს ბანკის ოფშორული ცენტრის ორი თანამშრომელი ჰაიდერაბადში (ინდოეთი). ისინი ბევრს მუშაობენ და ასრულებენ დავალებებს ოფიგენნო, მაგრამ ჯანდაბა, ეს სამუშაო აუტანელია.

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

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

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

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

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

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

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

თუ სწორად მახსოვს, საშუალოდ სჭირდება ოთხი სამუშაო დღე. საშუალოდ, დღეში დაახლოებით 700 ადამიანი ხსნის გამოწერას, საიდანაც 70% არის „პოტენციურად მნიშვნელოვანი“.

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

მთარგმნელის შენიშვნა: owl on KDPV - იოლ.

წყარო: www.habr.com