რამდენს ხარჯავთ ინფრასტრუქტურაზე? და როგორ შეგიძლიათ დაზოგოთ ფული ამაზე?

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

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

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

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

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

ვინ არის FinOps

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

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

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

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

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

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

ცოტა რამ ოპტიმიზაციის შესახებ

Ღრუბლები. შედარებით იაფი და ძალიან მოსახერხებელი. მაგრამ ეს გამოსავალი ჩერდება იაფი, როდესაც სერვერების რაოდენობა ორ ან სამ ციფრს აღწევს. გარდა ამისა, ღრუბლები შესაძლებელს ხდის უფრო და უფრო მეტი სერვისების გამოყენებას, რომლებიც ადრე მიუწვდომელი იყო: ეს არის მონაცემთა ბაზები, როგორც სერვისი (Amazon AWS, Azure Database), სერვერის აპლიკაციები (AWS Lambda, Azure Functions) და მრავალი სხვა. ისინი ყველა ძალიან მაგარია, რადგან მათი გამოყენება მარტივია - იყიდე და წადი, არანაირი პრობლემა. მაგრამ რაც უფრო ღრმად ჩავარდება კომპანია და მისი პროექტები ღრუბლებში, მით უფრო ცუდად სძინავს ფინანსური დირექტორი. და რაც უფრო სწრაფად ხდება გენერალი ნაცრისფერი.

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

რას აკეთებს FinOps ამ სიტუაციაში:

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

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

ან სხვა სიტუაცია: თქვენ შეიძინეთ სარეზერვო სიმძლავრე AWS-ზე ან Azure-ზე, რათა არ მოხვდეთ პიკური დატვირთვის ქვეშ. შეგიძლიათ დარწმუნებული იყოთ, რომ ეს არის ოპტიმალური გამოსავალი? ყოველივე ამის შემდეგ, თუ ეს შემთხვევები უმოქმედოა 80%, მაშინ თქვენ უბრალოდ აძლევთ ფულს Amazon-ს. უფრო მეტიც, ასეთი შემთხვევებისთვის, იგივე AWS-ს და Azure-ს აქვთ ადიდებული შემთხვევები - რატომ გჭირდებათ უმოქმედო სერვერები, თუ შეგიძლიათ გამოიყენოთ ინსტრუმენტი პიკური დატვირთვის პრობლემების გადასაჭრელად? ან On Premise ინსტანციების ნაცვლად, თქვენ უნდა მიხედოთ Reserved-ს - ისინი გაცილებით იაფია და ასევე გთავაზობთ ფასდაკლებებს.

სხვათა შორის, ფასდაკლების შესახებ

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

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

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

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

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

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

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

შედეგი?

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

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

წყარო: www.habr.com