FinOps практикада. Бұлтта ақшаны өртеуді қалай тоқтатуға болады
Дәл қазір ешкім пайдаланбайтын ресурстарға бұлттық шотыңыздан қанша ақша ағып жатқанына сенбейсіз.
Мен стартап инфрақұрылымын құрып жатырмын. Бұған дейін бүкіл Қазақстан бойынша энтерпрайз алаңдарда 18 жылдан астам, онда әрбір теңге есепте. Міне, парадокс: бюрократиясы мол корпорацияда қаржылық бақылау қатаң, ал бұлтта толық еркіндік. Дэвелопер terraform жазады, деплой жасайды, ұмытады. Биллинг айдың соңында келеді. Бәрі таң қалады.
Бұл ақша мәселесі емес. Бұл көрінімділік пен мәдениет мәселесі.

Ақша неге байқаусыз ағып кетеді
Міне, нақты кейс. Adobe. Жүктеме тестілеуі үшін уақытша масштабтаумен бірге жасалған бір Pull Request үш аптада $12,000 шығын әкелді. Бұл хакерлік емес, кодтағы баг емес. PR жай ілініп қалды, ешкім шығындарды қарамады, счётчик айнала берді.
SquareOps-тың 2026 жылғы деректері бойынша, ұйымдар бұлттық бюджеттің 20–35%-ын бекерге жұмсайды. CPU орташа утилизациясы небәрі 15–30% құрайды. Яғни уақыттың төрттен үшінде жай тұрып тыныс алатын сервер үшін төлейсіз.
Бұл «қоқыс» қайдан пайда болады:
- Жетімдер, яғни ешкімге қажет болмай қалған, бірақ ешкім жоймаған снапшоттар, дисктер, балансировщиктер
- 24/7 жұмыс жасайтын dev-орталар, мұнда дэвелоперлер ұйықтап жатқанда кластер түнде де, демалыс күндері де айналады
- Kubernetes-тегі асыра көтерілген resource requests, мұнда 4 CPU сұрайды, ал 0.3 пайдаланады
- Нашар bin packing, мұнда подтар дұрыс орналаспайды, нодтар жартылай бос
Дашбордтар мұнда көмектеспейді. Дашборд болып қойғанды көрсетеді. $12K кетіп қойды, PR мержделді (немесе жоқ), бірақ шот келген кезде үш аптадан кейін ғана білесіз.
Басқаша тәсіл қажет.
Шынымен жұмыс жасайтын 6 паттерн
1. Теггинг, яғни ерекшеліксіз барлығының негізі
Егер ресурс белгіленбесе, ол көрінбейді. Көрінбейтін ресурстарды ешкім оптимизацияламайды.
Әрбір ресурстағы минималды тег жиыны:
team: backend
service: payments-api
environment: production
owner: ilyas@company.com
Менің тәжірибемде ең жиі кездесетін мәселе, теггингті бүгін бастаған, ал ресурстардың жартысы бір жыл бұрын тегсіз жасалған. Бәрін бірден жасауға тырыспаңыз. Итеративтік тәсіл жұмыс жасайды:
- Құн бойынша дашборд көтер
- Тегсіз ресурстарды тап
- Белгіле
- Келесі аптада қайтала
Жалықтырады, бірақ бұл негіз. Тегтерсіз қай команда ақша өртеп жатқанын білмейсіз.
2. Cost-as-Code, яғни code review-дағы құн
Adobe кейсіне оралайық. Мәселе кімдір ашкөздік немесе ақылсыздық жасады деген емес. Мәселе мынада: өзгерістер құны шешім қабылдау сәтінде көрінбеді. Terraform жазды, PR ашты, reviewer код логикасын қарайды, ал мұның айына $4,000 тұратынын ешкім қарамайды.
Шешім Infracost. CI/CD-ге интеграцияланады, PR-ға комментарий ретінде тікелей құн дельтасын көрсетеді.
Шамамен былай көрінеді:
Estimated monthly cost change: +$3,847/mo
+ aws_instance.load_test r5.4xlarge +$876/mo
+ aws_rds.replica db.r5.2xl +$2,971/mo
Енді reviewer мұны мержге дейін көреді. Бұл бұғаттау емес, бұл сигнал. Заңды қымбат шешімдер бәрібір өтеді, тек саналы түрде.
Менің пікірімше, мен енгізген барлық нәрселердің ішінде бұл күш пен нәтиже арақатынасы ең жоғары тәсіл. Бір күнде орнатылады, үздіксіз жұмыс жасайды.
3. Қоқысты автоматты жою
Қолмен бұл жұмыс жасамайды. Адамдар ұмытады, «бөтен нәрсені» жоюдан қысылады, кейінге қалдырады.
cloud-nuke (Gruntwork-тен) жасы мен тегтері бойынша AWS-ресурстарын автоматты тазалауға арналған құрал. Dev/staging орталарда кесте бойынша іске қосасыз, do-not-delete: true тегі жоқ N күннен ескі барлығын жояды.
Бастауға арналған ең қарапайым сценарий:
# dev-дегі 7 күннен ескі барлық ресурстарды жою
cloud-nuke aws --region eu-west-1 \
--environment dev \
--older-than 168h
Стартаптағы менің тәжірибем бойынша, dev-орталар қоқыстың басты көзі. Біреу тестіледі, RDS, Redis, үш EC2 жасады, ұмытты. Бәрі айналып тұр.
Бөлек айтсақ, снапшоттар мен дисктер. Дәл қазір AWS Console → EC2 → Snapshots-қа кіріңіз. Жасалған күні бойынша сұрыптаңыз. Бас тартуға дайынмын, бұрыннан жоқ инстанстардан екі жылдық снапшоттар табасыз.
4. Rightsizing, яғни шынымен пайдаланатыныңыз үшін төлеу
Нарық бойынша орташа CPU утилизациясы небәрі 15–30%. Бұл инстанстардың басым бөлігін өнімділікке байқалатын әсерсіз екі есе кішірейтуге болатынын білдіреді.
Кандидаттарды қалай табуға болады:
- AWS Compute Optimizer тегін, консольде тікелей инстанс түрлері бойынша ұсыныстарды көрсетеді
- AWS Cost Explorer → Rightsizing Recommendations да тегін, нақты сандармен
Алгоритм қарапайым:
- Ұсыныстар тізімін аласыз
- Соңғы 2 апталық метрикаларды қарайсыз
- CPU < 20% және жады жетіп жатса, инстанс түрін кішірейтесіз
- Бір апта бақылайсыз
Менің тәжірибем бойынша, инженерлер production-ды кішірейтуден қорқады. Бұл қалыпты. Staging-нен бастаңыз, онда тәуекел нөл, деректер нақты.
5. Kubernetes: resource limits және bin packing
K8s бөлек ауру. Дэвелоперлер requests: cpu: 2 қояды, себебі «сақтандыру үшін». Жоспарлаушы нодтан осы сұраныстарға орын резервтейді, шынында сұралғанның 10%-ы пайдаланылады. Нод жартылай бос, бірақ бос орны жоқ болып есептеледі.
Не істеу керек:
Kubecost немесе OpenCost (open-source нұсқасы) namespace, deployment, тіпті жеке под бөлінісінде құнды көрсетеді. Кім асыра төлеп жатқанын бірден байқайсыз.
Минималды практикалар:
resources:
requests:
cpu: "100m" # нақты тұтыну, «сақтандыру үшін» емес
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
Сонымен қатар, dev-кластерлерді түнде және демалыс күндері өшіріңіз. Егер кластер тек жұмыс күндері 9-дан 18-ге дейін қажет болса, бұл аптадағы 168 сағаттың 128-ін үнемдейді. Dev-де 75% үнемдеу.
6. On-demand vs provisioned: жобалау кезінде ойлаңыз
Бұл мәдениет туралы, бірақ нақты мысалмен. DynamoDB-да on-demand режимін таңдасаңыз, нақты сұраулар үшін төлейсіз. Provisioned capacity дегеніміз резервтелгені үшін төлейсіз, пайдалансаңыз да, пайдаланбасаңыз да.
MVP және болжанбайтын жүктеме үшін on-demand жақсы. Тұрақты жоғары жүктеме үшін provisioned арзанырақ.
Немесе басқа мысал: ML-модель іске қосып жатырсыз. «ML = GPU» деп GPU-инстанс пайдаланасыз. Ал модель қарапайым классификация, ол CPU-да керемет жұмыс жасайды. GPU-инстанс 5–10 есе қымбат.
Инженер өзіне жобалау сәтінде құн туралы сұрақ қоюы тиіс, шот келген кезде емес.
Құралдар: не пайдалану керек
| Құрал | Не үшін | Бағасы |
|---|---|---|
| Infracost | PR/CI-дегі өзгерістер құны | Тегін (open-source) |
| AWS Cost Explorer | Шығындарды талдау, rightsizing | Тегін |
| AWS Compute Optimizer | Инстанстар бойынша ұсыныстар | Тегін |
| OpenCost | K8s-тегі namespace/pod бойынша құн | Тегін (open-source) |
| Kubecost | Дәл сол + ыңғайлы UI + alerting | Freemium |
| cloud-nuke | Dev/staging-де ресурстарды автожою | Тегін (open-source) |
Менің пікірімше, бастау үшін Cost Explorer + Infracost + cloud-nuke жеткілікті. Бұл нөл ақша және бір күн баптау.
Бір күнде қалай бастауға болады: чеклист
Бәрін бірден енгізудің қажеті жоқ. Міне, бүгін жасауға болатын минимум:
Таң (2–3 сағат):
- AWS Cost Explorer-ді ашып, өткен айдың топ-5 қымбат сервисін қарау
- Rightsizing Recommendations-ты қосып, кандидаттарды жазып алу
- EC2 → Snapshots-қа кіріп, 6 айдан ескі снапшоттарды табу
Күндіз (3–4 сағат):
- Infracost орнатып, terraform-мен бір репозиторийге интеграциялау
- Командамен келісу: инфрақұрылым PR-ларында құнды қараймыз
- Жаңа ресурстарға минималды тег жиынын орнату (team, environment, owner)
Кеш (1–2 сағат):
environmentтегісіз dev/staging ресурстарды табу- Түнде/демалыс күндері өшіруге болатындарды тізімдеу
- Dev-ортаға 7 күндік кезеңмен cloud-nuke орнату
Құрылымдалған оптимизация алғашқы 60 күнде 15–25% үнемдеу береді, SquareOps деректері бойынша. Бұл сиқыр емес, жай ретті жұмыс.
Бұл неге қаржы бөлімінің міндеті емес
Қаржы бөлімі шотты көреді. Инженер себепті көреді.
Қаржы бөлімі нақты EKS-кластерді 10 нодтан 6-ға зардапсыз кішірейтуге болатынын білмейді. Бір жыл бұрын жойылған инстанстан қалған снапшот екенін білмейді. Reserved instances үшін төлеу керек пе, әлде on-demand жақсы ма, бағалай алмайды.
FinOps тек инженерлер өз шешімдерінің құнына ие болған жағдайда ғана жұмыс жасайды. ActiveFence-тен Ноам Левидің сипаттауы бойынша бұл төрт компонент: көрінімділік, қысқа кері байланыс циклі, пайдалануды оптимизациялау және, ең маңыздысы, құнды есепке алатын ойлау жүйесі.
Соңғысы өздігінен пайда болмайды. Оны процестерге енгізу қажет: PR-да cost-as-code, командалар бойынша дашбордтар, жоспарлы жиналыстарда шығындарды тұрақты шолу.
Менің тәжірибем бойынша, дэвелопер өзінің PR-ы шотқа айына $2,000 қосатынын көрген кезде, ол басқаша ойлай бастайды. Қорқыныштан емес. Жай ғана ақпарат көрінімді болды.
Бұлт сиқыр да емес, тегін де емес. Бұл 24/7 айналып тұратын счётчик. Сіздің міндетіңіз ол не санайтынын білу.
Кішіден бастаңыз. Infracost-ты бүгін орнатыңыз. Cost Explorer-ге қараңыз. Бір қоқыс снапшот тауып, жойыңыз.
Бұл ештеңе жасамағаннан жақсы.


