मार्गदर्शिका

एक संगठन में निवारक सुरक्षा उपायों को लागू करें, जैसे संसाधन स्थानों को प्रतिबंधित करना या सेवा खाता कुंजी निर्माण को अक्षम करना।

→संगठन या फ़ोल्डर स्तर पर Organization Policy constraints (जैसे, `constraints/gcp.resourceLocations`, `constraints/iam.disableServiceAccountKeyCreation`) लागू करें।

क्यों: Organization Policies API स्तर पर विरासत में मिली और लागू की जाती हैं, जो गैर-अनुपालन वाली कार्रवाइयों को होने से पहले रोकती हैं। यह प्रतिक्रियाशील पहचान और उपचार से अधिक प्रभावी है।

संदर्भ↗

नीतियों और एक्सेस नियंत्रण को प्रभावी ढंग से प्रबंधित करने के लिए एक बहु-विभाग, बहु-वातावरण संगठन को संरचित करें।

→एक फ़ोल्डर पदानुक्रम डिजाइन करें, आमतौर पर: संगठन > व्यावसायिक इकाई (फ़ोल्डर) > वातावरण (जैसे, prod, staging) (उप-फ़ोल्डर) > प्रोजेक्ट्स।

क्यों: यह संरचना दानेदार नीति विरासत की अनुमति देती है। सामान्य नीतियां BU स्तर पर निर्धारित की जाती हैं, जबकि वातावरण-विशिष्ट नीतियां (जैसे, `prod` के लिए अधिक प्रतिबंधात्मक) वातावरण स्तर पर निर्धारित की जाती हैं।

लागत अनुकूलन के साथ अनुपालन, सुरक्षा विश्लेषण और परिचालन समस्या निवारण के लिए सभी प्रोजेक्ट्स से लॉग एकत्रित करें।

→एक संगठन-स्तरीय एग्रीगेटेड लॉग सिंक बनाएं। आवश्यकतानुसार लॉग को कई गंतव्यों पर रूट करें: विश्लेषण के लिए BigQuery, दीर्घकालिक/कम लागत वाले संग्रह के लिए Cloud Storage (Coldline/Archive), और SIEM पर रीयल-टाइम स्ट्रीमिंग के लिए Pub/Sub।

क्यों: यह टियर वाला दृष्टिकोण लागत और क्षमता दोनों के लिए अनुकूलन करता है। BigQuery शक्तिशाली क्वेरींग प्रदान करता है, जबकि Cloud Storage सस्ता संग्रह प्रदान करता है। सभी उपयोग मामलों के लिए एकल गंतव्य का उपयोग या तो बहुत महंगा है या पर्याप्त प्रदर्शनकारी नहीं है।

संदर्भ↗

BigQuery और Cloud Storage जैसी प्रबंधित सेवाओं से डेटा एक्सफ़िल्ट्रेशन को रोकें, केवल अधिकृत नेटवर्क या पहचान से पहुंच की अनुमति दें।

→संवेदनशील डेटा वाले प्रोजेक्ट्स के चारों ओर एक VPC Service Controls परिधि बनाएं। विशिष्ट IP श्रेणियों (कॉर्पोरेट नेटवर्क) या उपकरणों से पहुंच की अनुमति देने के लिए एक्सेस स्तरों को परिभाषित करें।

क्यों: VPC Service Controls API-आधारित सेवाओं के चारों ओर एक वर्चुअल परिधि बनाता है, परिधि के बाहर से पहुंच को अवरुद्ध करके चोरी हुई साख या गलत कॉन्फ़िगर की गई IAM नीतियों से जोखिमों को कम करता है।

सुरक्षा गार्डरेल स्थापित करें जिन्हें प्रोजेक्ट मालिकों द्वारा ओवरराइड नहीं किया जा सकता है, जैसे किसी विशिष्ट भूमिका को प्रदान करने से रोकना।

→संगठन या फ़ोल्डर स्तर पर IAM Deny नीतियां लागू करें। ये नीतियां स्पष्ट रूप से अनुमतियों को अस्वीकार करती हैं, और वे हमेशा किसी भी `allow` नीतियों को ओवरराइड करती हैं।

क्यों: Deny नीतियां संगठन-व्यापी सुरक्षा नियंत्रणों को लागू करने का एक शक्तिशाली तरीका प्रदान करती हैं जिन्हें संसाधन पदानुक्रम के निचले स्तरों पर बायपास नहीं किया जा सकता है, जिससे एक सुसंगत सुरक्षा स्थिति सुनिश्चित होती है।

सुनिश्चित करें कि सभी नए प्रोजेक्ट्स को एक मानक बेसलाइन कॉन्फ़िगरेशन (नेटवर्किंग, IAM, लॉगिंग, आदि) के साथ प्रावधानित किया गया है।

→"लैंडिंग ज़ोन" बनाने के लिए इन्फ्रास्ट्रक्चर एज़ कोड (जैसे, Cloud Build के साथ Terraform) का उपयोग करें। एक पाइपलाइन के माध्यम से प्रोजेक्ट निर्माण और कॉन्फ़िगरेशन को स्वचालित करें।

क्यों: स्वचालन निरंतरता सुनिश्चित करता है, मैन्युअल त्रुटि को कम करता है, और प्रोजेक्ट प्रावधान को गति देता है। यह सर्वोत्तम प्रथाओं को संहिताबद्ध करता है, जिससे शासन ऑडिट करने योग्य और दोहराने योग्य बनता है।

बाहरी प्रणालियों (जैसे GitHub Actions या ऑन-प्रेम CI/CD) को लंबे समय तक चलने वाली सेवा खाता कुंजियों का उपयोग किए बिना GCP संसाधनों तक पहुंचने की अनुमति दें।

→Workload Identity Federation कॉन्फ़िगर करें। एक प्रदाता बनाएं जो बाहरी IdP (जैसे, GitHub OIDC) पर भरोसा करता है और बाहरी पहचानों को एक GCP सेवा खाते में मैप करें। विशिष्ट रेपो/शाखाओं तक पहुंच को प्रतिबंधित करने के लिए विशेषता शर्तों का उपयोग करें।

क्यों: यह सेवा खाता कुंजियों को प्रबंधित और घुमाने की आवश्यकता को समाप्त करता है, जो एक बड़ा सुरक्षा जोखिम है। यह अल्पकालिक, पहचान-आधारित क्रेडेंशियल प्रदान करता है।

नेटवर्क प्रशासन (VPCs, सबनेट, फ़ायरवॉल) को केंद्रीकृत करें जबकि अलग-अलग टीमों को अपने स्वयं के प्रोजेक्ट संसाधनों का प्रबंधन करने की अनुमति दें।

→Shared VPC लागू करें। नेटवर्क संसाधनों के लिए एक "होस्ट प्रोजेक्ट" और एप्लिकेशन वर्कलोड के लिए "सेवा प्रोजेक्ट्स" बनाएं। सेवा प्रोजेक्ट पहचानों को `roles/compute.networkUser` प्रदान करें।

क्यों: Shared VPC नेटवर्क प्रशासन को प्रोजेक्ट प्रशासन से अलग करता है, केंद्रीयकृत नियंत्रण और सुरक्षा प्रदान करता है जबकि टीमों को स्वायत्तता देता है। यह इस उपयोग मामले के लिए VPC Peering से बेहतर स्केल करता है और अधिक सुरक्षित है।

एक Git रिपॉजिटरी से GKE क्लस्टर कॉन्फ़िगरेशन और एप्लिकेशन को घोषणात्मक रूप से प्रबंधित करें।

→manifests के लिए सत्य के एकल स्रोत के रूप में एक Git रिपॉजिटरी का उपयोग करें। रिपॉजिटरी में कॉन्फ़िगरेशन के साथ क्लस्टर स्थिति को लगातार समेटने के लिए GKE क्लस्टर्स में Config Sync स्थापित करें।

क्यों: GitOps Kubernetes को प्रबंधित करने का एक ऑडिट करने योग्य, संस्करण-नियंत्रित और स्वचालित तरीका प्रदान करता है। यह CI (कलाकृतियों का निर्माण) को CD (स्थिति का सिंक्रनाइज़ेशन) से अलग करता है।

गंभीर कमजोरियों वाले कंटेनर छवियों को डिप्लॉय होने से रोकें।

→Artifact Registry में स्वचालित भेद्यता स्कैनिंग सक्षम करें। Cloud Build पाइपलाइन में, एक चरण जोड़ें जो भेद्यताओं की जांच के लिए Container Analysis API का उपयोग करता है और यदि गंभीर समस्याएं पाई जाती हैं तो बिल्ड विफल कर देता है।

क्यों: यह CI पाइपलाइन में एक स्वचालित गुणवत्ता द्वार बनाता है, जो कमजोर कलाकृतियों को कभी भी डिप्लॉय करने योग्य स्थिति तक पहुंचने से रोकता है। यह सुरक्षा को बाईं ओर स्थानांतरित करता है।

रनटाइम पर यह लागू करें कि केवल विश्वसनीय, हस्ताक्षरित कंटेनर छवियों को GKE या Cloud Run पर डिप्लॉय किया जा सकता है।

→Binary Authorization लागू करें। attestors बनाएं (जैसे, भेद्यता स्कैन पास करने, QA साइन-ऑफ के लिए)। attestations बनाने के लिए CI पाइपलाइन कॉन्फ़िगर करें। GKE/Cloud Run पर एक नीति लागू करें जिसके लिए डिप्लॉयमेंट के लिए विशिष्ट attestations की आवश्यकता होती है।

क्यों: Binary Authorization डिप्लॉयमेंट के समय एक मजबूत, नीति-आधारित प्रवर्तन प्रदान करता है। यह समझौता की गई या बिना जांच की गई छवियों को डिप्लॉय करने से बचाता है, भले ही वे रजिस्ट्री में आ जाएं।

संदर्भ↗

Cloud Build रन के दौरान API कुंजियों या पासवर्ड जैसी संवेदनशील जानकारी को लॉग या स्रोत कोड में उजागर किए बिना एक्सेस करें।

→रहस्यों को Secret Manager में स्टोर करें। `cloudbuild.yaml` में, रहस्य को एक पर्यावरण चर या फ़ाइल के रूप में माउंट करने के लिए `availableSecrets` फ़ील्ड का उपयोग करें।

क्यों: यह देशी, सुरक्षित एकीकरण है। Cloud Build प्रमाणीकरण को संभालता है और लॉग से गुप्त मूल्यों को स्वचालित रूप से हटाता है, जिससे आकस्मिक जोखिम को रोका जा सकता है।

सॉफ्टवेयर कलाकृतियों के लिए हिरासत की एक सत्यापन योग्य श्रृंखला स्थापित करें ताकि यह सुनिश्चित हो सके कि उन्हें विश्वसनीय स्रोत कोड से एक विश्वसनीय प्रणाली द्वारा बनाया गया था।

→SLSA-अनुरूप provenance attestations उत्पन्न करने के लिए Cloud Build का उपयोग करें। इन attestations को छवियों के साथ Artifact Registry में स्टोर करें। डिप्लॉयमेंट से पहले provenance को सत्यापित करने के लिए Binary Authorization का उपयोग करें।

क्यों: SLSA सॉफ्टवेयर आपूर्ति श्रृंखला को मजबूत करने के लिए एक ढांचा प्रदान करता है। उपकरणों का यह संयोजन स्रोत से उत्पादन तक विश्वास की एक एंड-टू-एंड, सत्यापन योग्य श्रृंखला प्रदान करता है।

CI/CD जॉब्स चलाएं जिन्हें एक निजी VPC में संसाधनों तक पहुंचने की आवश्यकता है, जैसे एक निजी Artifact Registry या Cloud SQL डेटाबेस।

→एक Cloud Build प्राइवेट पूल बनाएं और पूल के नेटवर्क और आपके लक्ष्य VPC के बीच VPC peering कॉन्फ़िगर करें। इस पूल में चलने के लिए बिल्ड्स को कॉन्फ़िगर करें।

क्यों: निजी पूल नेटवर्क अलगाव प्रदान करते हैं और बिल्ड्स को इंटरनेट पर उजागर किए बिना एक निजी नेटवर्क पर संसाधनों को सुरक्षित रूप से एक्सेस करने की अनुमति देते हैं।

महत्वपूर्ण छवियों को बनाए रखते हुए भंडारण लागतों का प्रबंधन करने के लिए पुरानी या अप्रयुक्त कंटेनर छवियों को स्वचालित रूप से हटा दें।

→Artifact Registry cleanup नीतियों को कॉन्फ़िगर करें। `production` और `latest` जैसे टैग के लिए एक `keep` नीति का उपयोग करें। अन्य छवियों के लिए आयु, टैग पैटर्न और संस्करण गणना के आधार पर `delete` नीतियों का उपयोग करें।

क्यों: क्लीनअप नीतियां छवि जीवनचक्र को प्रबंधित करने का एक घोषणात्मक, स्वचालित तरीका प्रदान करती हैं, उत्पादन और हाल के विकास कलाकृतियों को बनाए रखने की आवश्यकता के साथ लागत बचत को संतुलित करती हैं।

अनुमोदन और प्रति वातावरण विभिन्न रणनीतियों के साथ dev से staging से production तक एक बहु-चरण डिप्लॉयमेंट को स्वचालित करें।

→लक्ष्यों (dev, staging, prod) की प्रगति के साथ एक एकल Cloud Deploy डिलीवरी पाइपलाइन को परिभाषित करें। उत्पादन लक्ष्य के लिए `requireApproval: true` कॉन्फ़िगर करें और प्रत्येक लक्ष्य के लिए विभिन्न डिप्लॉयमेंट रणनीतियों (जैसे, canary) को निर्दिष्ट करें।

क्यों: Cloud Deploy एक प्रबंधित, ऑडिट करने योग्य निरंतर वितरण सेवा प्रदान करता है। यह एकीकृत अनुमोदन और रोलबैक के साथ canary और blue-green डिप्लॉयमेंट जैसे प्रगतिशील वितरण पैटर्न को सरल बनाता है।

उपयोगकर्ता के दृष्टिकोण से सेवा की विश्वसनीयता को मापने के लिए मेट्रिक्स को परिभाषित करें।

→उपयोगकर्ता-सामना वाली चिंताओं के आधार पर Service Level Indicators (SLIs) को परिभाषित करें: उपलब्धता (सफल अनुरोधों का प्रतिशत), विलंबता (एक सीमा से तेज़ अनुरोधों का प्रतिशत), और शुद्धता/ताजगी (सही ढंग से संसाधित डेटा का प्रतिशत या अद्यतित है)।

क्यों: SLIs को आंतरिक सर्वर स्वास्थ्य के बजाय उपयोगकर्ता की खुशी को मापना चाहिए। CPU उपयोग जैसे मेट्रिक्स कारण हैं, जबकि उच्च विलंबता एक लक्षण है। SRE लक्षणों की निगरानी और प्रबंधन पर ध्यान केंद्रित करता है।

SLO उल्लंघनों के बारे में इतनी जल्दी सूचित किया जाए कि प्रतिक्रिया दी जा सके, बिना मामूली, क्षणिक समस्याओं के लिए अलर्ट से भर जाने के।

→SLO बर्न रेट (जिस गति से त्रुटि बजट का उपभोग किया जा रहा है) के आधार पर अलर्ट कॉन्फ़िगर करें। बहु-विंडो अलर्ट का उपयोग करें: महत्वपूर्ण पृष्ठों के लिए एक छोटी विंडो पर उच्च बर्न रेट, और गैर-जरूरी टिकटों के लिए एक लंबी विंडो पर कम बर्न रेट।

क्यों: बर्न रेट अलर्टिंग भविष्य कहनेवाला है। यह विफलता की *दर* पर अलर्ट करता है, जो एक वास्तविक समस्या को इंगित करता है, न कि एकल विफल अनुरोध को, जिससे अलर्ट थकान कम होती है और जो मायने रखता है उस पर ध्यान केंद्रित होता है।

संदर्भ↗

एक अनुरोध के पूर्ण जीवनचक्र को समझकर एक microservices वास्तुकला में विलंबता समस्याओं का निदान करें।

→OpenTelemetry SDKs के साथ सेवाओं को इंस्ट्रुमेंट करें और Cloud Trace में traces निर्यात करें। सुनिश्चित करें कि सेवा कॉलों (Pub/Sub जैसे मैसेज क्यू के माध्यम से सहित) में trace संदर्भ प्रचारित किया गया है।

क्यों: OpenTelemetry इंस्ट्रुमेंटेशन के लिए एक विक्रेता-तटस्थ मानक प्रदान करता है। Cloud Trace एंड-टू-एंड अनुरोध प्रवाह को विज़ुअलाइज़ करता है, जिससे यह पहचानना आसान हो जाता है कि कौन सी सेवा या ऑपरेशन बॉटलनेक है।

सुनिश्चित करें कि GKE में एप्लिकेशन लॉग सही ढंग से पार्स किए गए हैं, खोजने योग्य हैं, और Cloud Logging में उचित गंभीरता स्तर है।

→एप्लिकेशन को JSON प्रारूप में `stdout`/`stderr` पर लॉग लिखने के लिए कॉन्फ़िगर करें। एक `severity` फ़ील्ड शामिल करें जो Google Cloud के अपेक्षित मानों (जैसे, "INFO", "ERROR") से मेल खाता हो।

क्यों: GKE का डिफ़ॉल्ट लॉगिंग एजेंट स्वचालित रूप से stdout से JSON लॉग उठाता और पार्स करता है, जिससे वे साइडकार या कस्टम एजेंट की आवश्यकता के बिना Cloud Logging में संरचित और क्वेरी करने योग्य बन जाते हैं।

एक सेवा के लिए SLO अनुपालन और त्रुटि बजट खपत पर ट्रैक करें, विज़ुअलाइज़ करें और अलर्ट करें।

→Cloud Monitoring की Service Monitoring सुविधा का उपयोग करें। एक सेवा परिभाषित करें, SLIs (जैसे, एक लोड बैलेंसर से उपलब्धता) बनाएं, SLO लक्ष्य निर्धारित करें, और बर्न रेट अलर्टिंग नीतियों को कॉन्फ़िगर करें।

क्यों: यह देशी सुविधा SLO अनुपालन और त्रुटि बजट की जटिल गणनाओं को स्वचालित करती है, आउट-ऑफ-द-बॉक्स डैशबोर्ड प्रदान करती है, और अलर्टिंग सिस्टम के साथ एकीकृत होती है।

मेट्रिक्स, ट्रेस और लॉग को लिंक करके किसी समस्या का मूल कारण जल्दी से खोजें।

→सुनिश्चित करें कि trace IDs संरचित लॉग में शामिल हैं। मेट्रिक विसंगति के दौरान एक विशिष्ट trace पर कूदने के लिए मेट्रिक चार्ट पर trace exemplars जैसी Cloud Monitoring सुविधाओं का उपयोग करें, और फिर उस trace से, सहसंबंधित लॉग पर कूदें।

क्यों: अवलोकनीयता के तीन स्तंभों (मेट्रिक्स, लॉग, ट्रेस) के बीच सहजता से धुरी बनाने की क्षमता Mean Time to Resolution (MTTR) को कम करने की कुंजी है।

एप्लिकेशन-विशिष्ट घटनाओं के लिए कस्टम मेट्रिक्स और अलर्ट बनाएं जो केवल लॉग डेटा में उपलब्ध हैं, जैसे उपयोगकर्ता साइन-अप या भुगतान विफलताएं।

→Cloud Logging में, एक लॉग-आधारित मेट्रिक बनाएं। प्रासंगिक लॉग प्रविष्टियों से मेल खाने के लिए एक फ़िल्टर परिभाषित करें और मेट्रिक प्रकार (काउंटर या वितरण) को कॉन्फ़िगर करें। डैशबोर्ड और अलर्टिंग नीतियों में इस कस्टम मेट्रिक का उपयोग करें।

क्यों: लॉग-आधारित मेट्रिक्स आपको असंरचित या अर्ध-संरचित लॉग डेटा को संरचित समय-श्रृंखला डेटा में बदलने की अनुमति देते हैं, जिससे एप्लिकेशन कोड को बदले बिना व्यावसायिक-स्तर के KPIs पर निगरानी और अलर्ट करना आसान हो जाता है।

डेटाबेस में लोड जोड़े बिना डेटाबेस प्रदर्शन समस्याओं, जैसे धीमी प्रश्नों का निदान करें।

→Cloud SQL इंस्टेंस पर Cloud SQL Insights और Query Insights सक्षम करें। उच्च-लोड प्रश्नों की पहचान करने, निष्पादन योजनाओं का विश्लेषण करने और प्रदर्शन प्रवृत्तियों को देखने के लिए डैशबोर्ड का उपयोग करें।

क्यों: Query Insights हल्का, एजेंटलेस क्वेरी प्रदर्शन निगरानी प्रदान करता है। यह DBAs और डेवलपर्स को पारंपरिक प्रोफाइलिंग टूल के ओवरहेड के बिना अक्षम प्रश्नों का पता लगाने में मदद करता है।

बाहरी दृष्टिकोण से महत्वपूर्ण उपयोगकर्ता यात्राओं या API उपलब्धता की सक्रिय रूप से निगरानी करें।

→सरल HTTP/TCP जांचों के लिए Cloud Monitoring uptime जांचों का उपयोग करें। बहु-चरणीय उपयोगकर्ता प्रवाह (जैसे, लॉगिन, कार्ट में जोड़ें, चेकआउट) के लिए, Synthetic Monitors का उपयोग करें, जो एक प्रबंधित वातावरण में कस्टम स्क्रिप्ट (जैसे, Puppeteer) चलाते हैं।

क्यों: Synthetic monitoring वास्तविक उपयोगकर्ता इंटरैक्शन का अनुकरण करता है, जिससे आप उपयोगकर्ताओं के करने से पहले समस्याओं का पता लगा सकते हैं। यह बाहर से अंदर तक पूरे स्टैक का परीक्षण करता है।

सेवा विश्वसनीयता की आवश्यकता को नई सुविधाओं को जारी करने की आवश्यकता के साथ संतुलित करें।

→एक Service Level Objective (SLO) (जैसे, 99.9% उपलब्धता) परिभाषित करें। शेष 0.1% त्रुटि बजट है। यदि बजट अधिकतर बरकरार है, तो सुविधाएं भेजें। यदि बजट समाप्त हो गया है, तो सुविधा रिलीज़ रोकें और विश्वसनीयता सुधारों पर ध्यान केंद्रित करें।

क्यों: त्रुटि बजट जोखिम निर्णय लेने के लिए एक डेटा-संचालित ढांचा प्रदान करता है, इंजीनियरिंग, उत्पाद और व्यावसायिक टीमों को एक सामान्य लक्ष्य पर संरेखित करता है।

घटनाओं से सीखकर उन्हें दोबारा होने से रोकें, साथ ही मनोवैज्ञानिक सुरक्षा की संस्कृति को बढ़ावा दें।

→घटनाओं के बाद दोषरहित postmortems आयोजित करें। जांच को व्यक्तिगत पर दोषारोपण करने के बजाय प्रणालीगत कारकों, प्रक्रिया अंतराल और टूलिंग विफलताओं पर केंद्रित करें। आउटपुट कार्रवाई योग्य सुधार मदों की एक सूची होनी चाहिए।

क्यों: एक दोषरहित संस्कृति ईमानदार और खुले संचार को प्रोत्साहित करती है, जिससे एक घटना के मूल कारणों की अधिक सटीक समझ और अधिक प्रभावी निवारक कार्रवाई होती है।

प्रमुख घटना पर प्रतिक्रिया को प्रभावी ढंग से समन्वित करें, भ्रम और दोहराए गए प्रयासों से बचें।

→स्पष्ट रूप से परिभाषित भूमिकाओं के साथ एक Incident Command System (ICS) लागू करें: Incident Commander (समग्र समन्वय), Operations Lead (तकनीकी जांच/फिक्स), और Communications Lead (हितधारक अपडेट)।

क्यों: ICS घटना प्रतिक्रिया के लिए एक मानकीकृत, स्केलेबल संरचना प्रदान करता है, जो अधिकार और संचार की स्पष्ट रेखाओं को सुनिश्चित करता है, जो जटिल मुद्दों को जल्दी से हल करने के लिए महत्वपूर्ण है।

एक सॉफ्टवेयर वितरण संगठन के प्रदर्शन को मापें।

→चार प्रमुख DORA मेट्रिक्स को ट्रैक करें: Deployment Frequency (कितनी बार), Lead Time for Changes (कमिट से डिप्लॉय तक कितनी तेजी से), Change Failure Rate (कितने प्रतिशत डिप्लॉयमेंट विफलता का कारण बनते हैं), और Time to Restore Service (MTTR)।

क्यों: ये चार मेट्रिक्स विकास वेग और परिचालन स्थिरता दोनों का एक संतुलित दृश्य प्रदान करते हैं, और उच्च-प्रदर्शन वाले संगठनों के साथ सहसंबंधित होने के लिए सिद्ध हुए हैं।

एक SRE टीम मैन्युअल, दोहराए जाने वाले परिचालन कार्यों (toil) पर बहुत अधिक समय खर्च कर रही है, इंजीनियरिंग परियोजनाओं के लिए कोई समय नहीं छोड़ रही है।

→सबसे अधिक समय लेने वाले toil की पहचान करें और उसे मापें। इन कार्यों को प्राथमिकता दें और स्वचालित करें (जैसे, मैन्युअल स्केलिंग के बजाय autoscaling लागू करना, सामान्य अलर्ट के लिए ऑटो-रेमेडिएशन)। इंजीनियर के समय का < 50% पर toil को सीमित करें।

क्यों: Toil उत्पादकता और मनोबल पर एक खिंचाव है। स्वचालन के माध्यम से इसे व्यवस्थित रूप से कम करने से इंजीनियरों को दीर्घकालिक विश्वसनीयता सुधारों पर काम करने के लिए समय मिलता है।

एक साझा बुनियादी ढांचे में विभिन्न टीमों, सेवाओं या वातावरणों को क्लाउड लागतों को सटीक रूप से विशेषता दें।

→एक सुसंगत लेबलिंग/टैगिंग रणनीति लागू करें। Cloud Billing रिपोर्ट में फ़िल्टर करने के लिए इन लेबलों का उपयोग करें। GKE के लिए, namespace या workload द्वारा लागतों को विभाजित करने के लिए GKE cost allocation सक्षम करें।

क्यों: सटीक लागत आवंटन दृश्यता प्रदान करता है, जो जवाबदेही को बढ़ावा देता है। जो टीमें अपना खर्च देख सकती हैं, उन्हें इसे अनुकूलित करने का अधिकार है।

वर्कलोड के विविध सेट (स्थिर, बाधित करने योग्य, dev/test) के लिए कंप्यूट लागतों का अनुकूलन करें।

→वर्कलोड को मूल्य निर्धारण मॉडल से मिलाएं। स्थिर, 24/7 वर्कलोड के लिए Committed Use Discounts (CUDs) का उपयोग करें। दोष-सहिष्णु, बाधित करने योग्य नौकरियों (जैसे, बैच प्रोसेसिंग) के लिए Spot VMs का उपयोग करें। व्यावसायिक घंटों के बाहर बंद होने के लिए dev/test वातावरण को शेड्यूल करें।

क्यों: कंप्यूट मूल्य निर्धारण के लिए एक आकार-सभी फिट दृष्टिकोण अक्षम है। कार्य के लिए सही उपकरण का उपयोग करने से प्रदर्शन को प्रभावित किए बिना महत्वपूर्ण बचत (>70%) हो सकती है।

यह सुनिश्चित करके GKE लागतों और प्रदर्शन का अनुकूलन करें कि पॉड्स CPU और मेमोरी की उचित मात्रा का अनुरोध कर रहे हैं।

→Vertical Pod Autoscaler (VPA) को `recommendation` मोड में डिप्लॉय करें। पॉड संसाधन `requests` को समायोजित करने के लिए इसके सुझावों का विश्लेषण करें। एक बार आश्वस्त होने पर, निरंतर राइट-साइज़िंग के लिए `auto` मोड पर स्विच करें।

क्यों: पॉड्स का अधिक प्रावधान पैसे बर्बाद करता है, जबकि कम प्रावधान प्रदर्शन समस्याओं (थ्रॉटलिंग, OOMKilled) का कारण बनता है। VPA वास्तविक उपयोग डेटा का उपयोग सटीक साइजिंग अनुशंसाएं करने के लिए करता है, जिससे दक्षता और स्थिरता दोनों में सुधार होता है।

Cloud Run सेवा के लिए कोल्ड स्टार्ट के कारण होने वाली विलंबता को कम करें।

→कई इंस्टेंस को गर्म रखने के लिए एक `min-instances` मान कॉन्फ़िगर करें। इसके अतिरिक्त, कंटेनर छवि (छोटी आधार छवि, कम परतें) और एप्लिकेशन स्टार्टअप कोड (आलसी आरंभीकरण) का अनुकूलन करें।

क्यों: `min-instances` कोल्ड स्टार्ट को कम करने का सबसे सीधा तरीका है, लेकिन इसकी एक लागत है। इसे कंटेनर और कोड अनुकूलन के साथ संयोजित करने से प्रदर्शन और लागत के लिए एक संतुलित दृष्टिकोण मिलता है।

चर क्वेरी पैटर्न के साथ एक बड़े पैमाने पर BigQuery एनालिटिक्स वर्कलोड के लिए लागतों का अनुकूलन करें।

→ऑन-डिमांड मूल्य निर्धारण से BigQuery Editions (स्लॉट) पर स्विच करें। अनुमानित लोड के लिए एक बेसलाइन स्लॉट प्रतिबद्धता खरीदें और पीक के लिए autoscaling सक्षम करें। इसके अतिरिक्त, विभाजन/क्लस्टर्ड तालिकाओं का उपयोग करके और `SELECT *` से बचकर प्रश्नों का अनुकूलन करें।

क्यों: सुसंगत वर्कलोड के लिए, स्लॉट-आधारित मूल्य निर्धारण ऑन-डिमांड की तुलना में अधिक लागत प्रभावी है। autoscaling लागतों को नियंत्रित करते हुए बर्स्ट के लिए लचीलापन प्रदान करता है। क्वेरी और तालिका अनुकूलन संसाधित डेटा की मात्रा को कम करता है, जिससे सीधे लागत कम होती है।

विश्व स्तर पर वितरित एप्लिकेशन के लिए उच्च नेटवर्क निकास लागतों को कम करें।

→उपयोगकर्ताओं के करीब, एज पर स्थिर सामग्री को कैश करने के लिए Cloud CDN का उपयोग करें। गतिशील ट्रैफिक के लिए, उपयुक्त Network Service Tier (प्रदर्शन के लिए Premium, लागत-बचत के लिए Standard) चुनें। क्रॉस-रीजन ट्रैफिक को कम करने के लिए डेटा को क्षेत्रीय रूप से संसाधित करें।

क्यों: Egress एक प्रमुख लागत चालक है। CDN मूल से ट्रैफिक को ऑफलोड करता है, सीधे Egress को कम करता है। नेटवर्क टियर और क्षेत्रीय डेटा प्रोसेसिंग का विचारशील उपयोग लागतों को काफी कम कर सकता है।