ღრუბლოვანი ხარჯების ოპტიმიზაცია

1) რატომ FinOps და რა მიზნები აქვს

• რამდენი ღირს 1 მოთხოვნა, 1 აქტიური მომხმარებელი, 1 ტენანტი?
• რა ზღვრული ეფექტი აქვს ახალ ფიჩერს/ტრაფიკს?
• სად არის „გაჟონვა“ (egress, ჭარბი შრიფტები, CPU/მეხსიერების ზეგანაკვეთი, უსაქმური რესურსები)?

საბაზო მეტრიკა

Cost/Req, Cost/Minute Active, Cost/Tenant/Brand, Cost/GB-stored, Cost/GB-egress.
COGS%: შემოსავლის ღირებულების წილი.
Waste%: (გადახდილი, მაგრამ გამოუყენებელი რესურსები )/( ყველა რესურსი).

2) წესრიგის აღდგენა: ტეგები, ფლობა, ბიუჯეტები

დაანგარიშება/ეტიკეტები: 'env', 'team', 'service', 'tenant', 'product', 'cost _ center', 'slo _ tier'.
ფლობა: თითოეულ რესურსს აქვს მფლობელი და TTL.
ბიუჯეტები/ალერტები: ყოველთვიური/ყოველკვირეული ბიუჯეტები 50/80/100% + ანომალიური დეკლარაციით.
პოლიტიკოსები, როგორც კოდი: აკრძალვა „ტეგების გარეშე“, ზომების ლიმიტები, ნაგულისხმევი რეგიონები, გამოყოფილი კვოტები.

hcl module "policy" {
source = "finops/policy/required-tags"
required_tags = ["env","team","service","cost_center","tenant"]
}

3) ეკონომიკის არქიტექტურული ბერკეტები

3. 1 სწორი ზომები და სკეილინგი

Rightsizing: შეარჩიეთ ინსტანციები ფაქტობრივი CPU/RAM p95.
ავტო სკეილინგი: ჰორიზონტალი> ვერტიკალური; для K8s — Cluster Autoscaler/Karpenter, для serverless — min/max concurrency.
ცივი ბილიკები - რიგში/ბატჩებში; გრძივი დავალებები - გრაფიკის შემსრულებლები.

3. 2 ადგილზე/შეძენილი შესაძლებლობები

Spot/Preemptible სტეიტლის/ფონი და CI; შეინახეთ On-Demand ბუფერი.
RI/CUD/Savings Plans: დაჯავშნეთ საბაზო დატვირთვის სტაბილური 50-70%, დანარჩენი ელასტიური.

3. 3 მონაცემთა შენახვა და კლასები

გაყოფა: ცხელი (SSD), warm (სტანდარტული), cold/არქივი (Glacier/Archive).
ცხოვრების ციკლის პოლიტიკოსები: კლასების ცვლა, განთავისუფლება ვადის გასვლის შემდეგ.
ჩართეთ ვერსია, სადაც საჭიროა, და object lock (WORM) - მხოლოდ აუდიტისთვის.

3. 4 ქსელი და egress

CDN/edge + stale-while-revalidate ამცირებს რეგიონალურ egress.
პირადი არხები (PrivateLink/PSC/Direct Connect/Interconnect) „ნედლეული“ ინტერნეტის ნაცვლად.
კომპრესია (Brotli/Zstd), HTTP/3/QUIC - ნაკლები ვიდრე RTT/ხელახლა ჩართვა.

3. 5 მონაცემთა ბაზა და ქეში

შეარჩიეთ ორ დონის სქემა: ქეში (Redis/Memcached) + საცავი.
წაიკითხეთ ანალიტიკოსების შენიშვნები, ჩართეთ ავტო-ვაკუუმი/კომპონენტი, გამოიყენეთ pgBouncer/RDS Proxy.
დიდი ცხრილებისთვის - განლაგება/TTL/არქივი.

4) Kubernetes ეკონომიკა

Requests/Limits SLO კლასებში; აკრძალვა 'limits: null'.
VPA (რეკომენდაციები), Karpenter (ინსტალაციის შერჩევა), Bin packing (tolerations/affinity).
გაყოფილი scream/stage/dev კლასტერის/კვანძების დონეზე (სხვადასხვა ტიპები და პოლიტიკა).
ქსელური და სტანდარტული კლასები: შეარჩიეთ SC/IOPS დატვირთვის პროფილის მიხედვით და არა „პრემია ყველგან“.
QoS კლასები და პრიორიტეტები: დაზოგვა ფონის დავალებებზე.
ლოგოების პროფილები: sidecar აგენტები ადგილობრივი ბუფერით, გაგზავნეთ ბრძოლები.

5) Serverless ეკონომიკა

Min instances/provisioned concurrence - მხოლოდ ცხელი სახელურებისთვის.
პატარა deple-bandle, lazy-init, connect sharing.
რთული დავალებების შესრულებისა და შესრულების ვადები.
აგრეგატორის ფუნქციები დამოკიდებულია ათეულობით კამპანიის ნაცვლად.

6) გადახდა ტელემეტრიისთვის

Logs: სტრუქტურული, verboseness- ის გარეშე; კლასების რეტენციები (უფრო მეტხანს დაშვებული შეცდომები, debug - მოკლედ).
Sampling trases: tail-based - შეცდომების 100 %/p99, დანარჩენი 1-10%.
მეტრიკა: აგრეგაცია/დაშლა, sparse გაგზავნა.
გაგზავნამდე PII ფილტრაცია (ნაკლები ბაიტი და რისკი).

7) მომწოდებლების ქსელი და მარკეტინგი

შეადარეთ რეგიონების ფასები, მენეჯმენტის სტანდარტული სერვისების ზღვარი, ბანდების ბაზარი.
მოლაპარაკებები: მოცულობითი ფასდაკლება (RI/CUD), კომუნალური ხელშეკრულებები, საკრედიტო პროგრამები.
თავიდან აიცილეთ SaaS დუბლირება გადაკვეთილი ფუნქციონალით.

8) ერთეულის ეკონომიკა და დაშბორდი

ძირითადი SLI/SLO ღირებულება

Cost/Req მარშრუტებზე (login, catalog, deposit).
Cost/Tenant/Brand/Region.
Egress/Req, Storage/Req, Compute/Req.
Waste % и Coverage RI/SP %.

დაშბორდი (მინიმალური ნაკრები)

„ხარჯების რუკა“ სერვისებისთვის/ბრძანებებისთვის, რესურსით დაღმართებით.
„თერმული ბარათი“ სფეროებში.
„სერვისი - ღირებულება SLO“: კორელაცია p99 და Cost/Req.
„RI/CUD/Spot“ დაფარვა და დაზოგვა ხაზების გასწვრივ.

9) FinOps პროცესები

ყოველკვირეული ანგარიშების ანალიზი მომსახურების მფლობელებთან.
Change Review, რომელიც აფასებს ფიგურების ღირებულებას პროდ ჩართვამდე.
Guardrails: კვოტების ლიმიტები, idle რესურსების ავტომატური დასრულება, TTL ტესტის გარემოში.
GameDays ღირებულება: ხელოვნური მწვერვალები/წინა დროშები, ბიუჯეტის სტაბილურობის შემოწმება.

10) ანტიპატერები

TTL- ს გარეშე „დროებითი“ რესურსები სამუდამოდ ხდება.
`0. 0. 0. 0/0 'egress + არ არსებობს CDN - აფეთქებულია ანგარიშები.
ტეგების/ეტიკეტების გარეშე, შეუძლებელია ხარჯების განაწილება.
DEBUG დონის ლოგოები იყიდება, 100% ხრიკები უაზრო ტერაბაიტებია.
Provisioned/serverful „მხოლოდ შემთხვევაში“ მეტრიკის გამოყენების გარეშე.
ყველა დატვირთვა - მხოლოდ On-Demand, RI/Spot/commite- ის გარეშე.

11) iGaming/ფინანსების სპეციფიკა

PSP/გადახდის კომისიები - COGS- ის ნაწილი: ოპტიმიზაცია მოახდინეთ smart-routing იაფი/საიმედო პროვაიდერებისთვის; გადააკეთეთ სტატუსები, თავიდან აიცილეთ გამეორება იდემპოტენტურობის გარეშე.
KYC/AML გამყიდველები: შეავსეთ მოთხოვნები, გამოიყენეთ შედეგების ქეში (TTL პოლიტიკის შესახებ), გაზომეთ Cost/KYC.
„ფულის გზები“ (ანაბარი/გამომავალი): ცალკეული SLO და ბიუჯეტი; რეზერვები პიკის მოვლენებისთვის, თბილი ნიმუშები მხოლოდ იქ არის.
შინაარსი/CDN: ადგილობრივი edge და რეგიონალური დომენები, რათა შემცირდეს egress და დაიცვან მონაცემები.
იურიდიული მოთხოვნები: აუდიტის WORM საცავი - შეზღუდეთ მოცულობა (აგრეგაცია, TTL, კომპრესია).

12) მინი რეცეპტები

12. 1 ჭრიჭინების პოლიტიკა

Strangs შეცდომები: 30-90 დღე; Info: 7–14; Debug: 24-72 საათი.
არქივი მხოლოდ შესაბამისობის მოთხოვნით.

12. 2 კანარის ტელემეტრია

ახალი ფიჩისთვის - 100% ტრეისი პირველი 24 საათის განმავლობაში, შემდეგ tail-sampling.

12. 3 ობიექტების ცხოვრების ციკლები

json
[
{"prefix": "raw/", "days_to_warm": 30, "days_to_cold": 90, "days_to_delete": 365},
{"prefix": "audit/", "lock": "WORM-365d"}
]

12. 4 ბიუჯეტები/ალერტები (იდეა)

13) მზადყოფნის ჩეკის სია

• ტეგი და მეპატრონეები 100% რესურსით; პოლიტიკოსები დაბლოკავენ.
• ბიუჯეტები და ალერტები + ანომალიური გამოცემა; მოხსენებები ტენანტების/ბრენდების/რეგიონების შესახებ.
• RI/CUD/Spot მოიცავს საბაზო დატვირთვას; არის On-Demand ბუფერი.
• K8s: requests/limits მოცემულია; VPA/Karpenter; bin packing; ცალკეული საგუშაგო/IOPS კლასები.
• Serverless: provisioned/min მხოლოდ ცხელი ბილიკებისთვის; ცივი - რიგებით.
• CDN/edge შედის; კერძო არხები PaaS- სთვის; egress dashboord.
• Logs/traces: tail-sampling, კლასები; ფილტრაცია PII.
• ცხოვრების ციკლები და არქივი; დიდი ცხრილების განლაგება.
• ფინანსური დაშბორდები Cost/Req, Cost/Tenant, Waste%, Coverage RI/SP%.
• iGaming- ისთვის: PSP/KYC/AML ხარჯების აღრიცხვა, SLO და „ფულის გზების“ ბიუჯეტები, WORM აუდიტი.

14) TL; DR

ჯერ ხილვადობა (ტეგები, ბიუჯეტები, დაშბორდები), შემდეგ სტრუქტურული ბერკეტები: სწორი ზომები, ავტო სკეილინგი, RI/Spot/კომუნები, CDN/edge და პირადი არხები, შენახვის კლასები და ცხოვრების ციკლები. გადაიხადეთ ღირებული ტელემეტრია (tail-sampling, მოკლე რეტენციები) და ავტომატიზაცია guardrails. IGaming- ში გაითვალისწინეთ PSP/KYC/AML, როგორც COGS- ის ნაწილი და გამოყავით „ფულის ბილიკები“ ინდივიდუალური SLO და ბიუჯეტებით.