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

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

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

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

ერთი თვით ადრე

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

Teaching Strategies არის ბაზრის ლიდერი სასწავლო გეგმებში ძალიან მცირეწლოვანი ბავშვებისთვის დაბადებიდან სამ წლამდე. ტრადიციული „ქაღალდის“ კომპანია უკვე 40 წლისაა, პლატფორმის ციფრული SaaS ვერსია კი 10 წლისაა, შედარებით ცოტა ხნის წინ დაიწყო ციფრული ტექნოლოგიების კომპანიის სტანდარტებთან ადაპტაციის პროცესი. "ახალი" ვერსია 2017 წელს დაიწყო და თითქმის ძველს ჰგავდა, მხოლოდ უარესად მუშაობდა.

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

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

პლატფორმას, რომელიც თითქოს მხოლოდ 2 წლის იყო, ჰქონდა თავისებური სტეკი: ColdFusion & SQL Server 2008 წლიდან. ColdFusion, თუ არ იცით და დიდი ალბათობით არ იცით, არის საწარმოს PHP, რომელიც გამოვიდა 90-იანი წლების შუა ხანებში და მას შემდეგ არც კი მსმენია ამის შესახებ. ასევე იყო: Ruby, MySQL, PostgreSQL, Java, Go, Python. მაგრამ მთავარი მონოლითი მუშაობდა ColdFusion-ზე და SQL Server-ზე.

პრობლემები

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

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

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

ორი დღით ადრე

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

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

პირველი დღე

გავიდა ორი დღე და მუშაობის პირველ დღეს აღმოვაჩინე, რომ პრობლემა არ გამქრალა.

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

- დიახ, ბილეთი გავხსენით.
- და?
- კარგი, ჯერ არ გვიპასუხეს.

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

არის კარგი ციტატა, რომელიც კარგად ერგება ამას:

”ზოგჯერ ტექნოლოგიის შესაცვლელად, თქვენ უნდა შეცვალოთ ორგანიზაცია.”

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

მესამე დღე

ასე რომ, დატვირთვა გრძელდება 4 წამი, ხოლო 13-დან 15-მდე ყველაზე დიდი მწვერვალები.

მესამე დღეს ამ პერიოდის განმავლობაში ჩამოტვირთვის სიჩქარე ასე გამოიყურებოდა:

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

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

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

- მრცხვენია, რომ ვიკითხო, მაგრამ 150 გაყოფილი 17-ზე იძლევა დაახლოებით 8-ს? თქვენ ამბობთ, რომ თითოეული სერვერი იძლევა 8 მოთხოვნას წამში და თუ ხვალ იქნება 160 მოთხოვნა წამში, დაგვჭირდება კიდევ 2 სერვერი?

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

var currentClass = classes.getCurrentClass();
return currentClass;

იყო ფუნქცია getCurrentClass(), რადგან საიტზე ყველაფერი მუშაობს კლასის კონტექსტში - ეს ასეა. და ამ ფუნქციისთვის თითოეულ გვერდზე იყო 200+ მოთხოვნა.

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

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

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

მაგრამ ამ პირველი პრობლემის გადაჭრამ გრაფიკი გაცილებით დაბლა ჩამოაგდო.

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

მეათე დღე

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

კიდევ ერთხელ აღმოაჩინეს რაღაც საინტერესო. გუნდი შედგებოდა: 18 დეველოპერისგან; 8 ტესტერი; 3 მენეჯერი; 2 არქიტექტორი. და ყველანი მონაწილეობდნენ საერთო რიტუალებში, ანუ ყოველ დილით 30-ზე მეტი ადამიანი მოდიოდა სტენდ-აპზე და ეუბნებოდათ რას აკეთებდნენ. ცხადია, შეხვედრას არც 5 და არც 15 წუთი დასჭირდა. არავინ არავის უსმენდა, რადგან ყველა მუშაობს სხვადასხვა სისტემაზე. ამ ფორმით, მოვლის სესიაზე საათში 2-3 ბილეთი უკვე კარგი შედეგი იყო.

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

შედეგად მივიღეთ:

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

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

დღე მეთერთმეტე

გუნდის სტრუქტურის შეცვლის პროცესში აღმოვაჩინე როგორ უნდა დათვლა ისტორიაქულა. 1 SP უდრიდა ერთ დღეს და თითოეული ბილეთი შეიცავდა SP-ს როგორც განვითარებისთვის, ასევე QA-სთვის, ანუ მინიმუმ 2 SP.

როგორ აღმოვაჩინე ეს?

ჩვენ აღმოვაჩინეთ ხარვეზი: ერთ-ერთ მოხსენებაში, სადაც შეყვანილია იმ პერიოდის დაწყების და დასრულების თარიღი, რომლისთვისაც საჭიროა ანგარიში, ბოლო დღე არ არის გათვალისწინებული. ანუ, სადღაც მოთხოვნაში არ იყო <=, არამედ უბრალოდ <. მითხრეს, რომ ეს არის სამი ამბავი, ანუ 3 დღის.

ამის შემდეგ ჩვენ:

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

დღე მეოცე

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

გრძელვადიანი მიზნები:

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

წარსულში ხშირად ამბობდნენ: "მოდით, ყველაფერი გადავიწეროთ [ენაზე/ჩარჩოში], ყველაფერი უკეთესად იმუშავებს!"

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

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

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

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

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

როგორ შეგიძლიათ მხარი დაუჭიროთ მიზანს, გქონდეთ მეტი ახალი პროდუქტი?

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

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

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

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

დღე ოცდაათი

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

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

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

ნათელია, რამდენად შორს ვიყავით n-1-დან, თუ პლატფორმა დაფუძნებული იყო ColdFusion-სა და SQL Server 2008-ზე, რომელიც ივლისში საერთოდ აღარ იყო მხარდაჭერილი.

დღე ორმოცდამეხუთე

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

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

როდესაც ეს გავაკეთე, ორი რამ მიიქცია თვალი:

• QA-დან დეველოპერებს დაბრუნებული ბილეთების მაღალი პროცენტი;
• გაყვანის მოთხოვნის განხილვას ძალიან დიდი დრო დასჭირდა.

პრობლემა ის იყო, რომ ეს იყო დასკვნები, როგორიცაა: როგორც ჩანს, ამას დიდი დრო სჭირდება, მაგრამ ჩვენ არ ვიცით რამდენი ხანი.

"თქვენ არ შეგიძლიათ გააუმჯობესოთ ის, რისი გაზომვაც არ შეგიძლიათ."

როგორ უნდა დაასაბუთოთ რამდენად სერიოზულია პრობლემა? დღეებს კარგავს თუ საათებს?

ამის გასაზომად, ჩვენ დავამატეთ Jira-ს პროცესს რამდენიმე ნაბიჯი: „მზადაა განვითარებისთვის“ და „მზადაა QA-სთვის“, რათა გავზომოთ რამდენი ხანი ელის თითოეული ბილეთი და რამდენჯერ უბრუნდება გარკვეულ საფეხურს.

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

• პროცესის ეფექტურობა: შესრულება და დაგეგმილი/მიწოდებული.
• პროცესის ხარისხი: დეფექტების რაოდენობა, დეფექტები QA-დან.

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

დღე ორმოცდამეათე

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

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

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

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

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

ორმოცდამეერთე დღე

დავიწყე გუნდში ყურადღებით დათვალიერება, რომ გამეგო ვინ მყავდა და კიდევ ერთხელ გამახსენდა:

”პრობლემების უმეტესობა ხალხის პრობლემებია.”

მე აღმოვაჩინე, რომ გუნდს, როგორც ასეთს - Dev-საც და Ops-საც - სამი დიდი პრობლემა აქვს:

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

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

მაგრამ თქვენ ვერ გახდებით უკეთესი არაფრის შეცვლის გარეშე.

აბსოლუტურად აბსურდული საუბარი მქონდა თანამშრომელთან, ვუთხარი ჩემი იდეები ოპტიმიზაციის შესახებ, რაზეც მან მითხრა:
- ოჰ, შენ არ ნახე რა გვქონდა შარშან!
- Მერე რა?
”ახლა ბევრად უკეთესია, ვიდრე იყო.”
- მაშ, უკეთესი არ შეიძლება?
- Რისთვის?

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

• ჩატვირთვა 12 წამი;
• ყოველი გამოშვების 5-10 წუთი შესვენება;
• კრიტიკული პრობლემების მოგვარებას დღეები და კვირები სჭირდება;
• მორიგე პერსონალის ნაკლებობა 24x7 / გამოძახებით.

არავის არასდროს უცდია ეკითხა, რატომ არ ვაკეთებთ ამას უკეთესად და ვერავინ მიხვდა, რომ ასე არ უნდა იყოს.

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

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

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

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

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

საპასუხოდ, მე შემოვიღე შემდეგი პრაქტიკა:

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

დღე სამოცი

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

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

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

ინვენტარიზაციის შედეგები:

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

სამოცდამეხუთე დღე

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

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

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

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

ანუ ColdFusion გადის Jetty-სა და nginx-ში და გაუშვებს გვერდებს. და სურათები, JS და CSS გადიან ცალკე nginx-ს საკუთარი კონფიგურაციით. ეს არის საკმაოდ სტანდარტული პრაქტიკა, რომელზეც მე ვსაუბრობ წერდა რამოდენიმე წლის წინ. შედეგად, სურათები ბევრად უფრო სწრაფად იტვირთება და... ჩატვირთვის საშუალო სიჩქარე 200 ms-ით გაიზარდა.

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

ოთხმოცდამეხუთე დღე

მესამე თვის ბოლოს მივხვდი, რომ იყო ერთი რამ, რისი იმედიც საერთოდ არ მქონდა: დრო. ყველაფერს, რაზეც ვისაუბრე, დრო სჭირდება.

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

დასკვნა

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

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

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

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

ამით ყველაფერი დანარჩენი მოვა.

ლეონ ცეცხლი ტვიტერზე, facebook და საშუალო.

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

წყარო: www.habr.com