आपसे कहा गया है कि reliability को नुकसान पहुंचाए बिना क्लाउड खर्च तीस प्रतिशत घटाइए। आपका प्लान क्या है?

पहले दिखाई देना पक्का करें, खर्च को service, environment और टीम के हिसाब से बांटें, फिर सूची को मेहनत और जोखिम के क्रम में निपटाएं। ऐसी बर्बादी से शुरू करें जिसका reliability पर कोई असर नहीं: बेकार पड़े resource, बिना जुड़े volume, जरूरत से बड़े instance, रातभर चलते non production environment, और log retention। फिर स्थिर baseline के लिए reserved या savings plan लें। उसके बाद ही आर्किटेक्चर के बदलाव सोचें, और हर प्रस्ताव डेटा के साथ मालिक टीम के पास ले जाएं।

मैं काटने से शुरू नहीं करूंगा, मैं नापने से शुरू करूंगा, क्योंकि टीम और environment के हिसाब से allocation के बिना हर बातचीत बहस बन जाती है। जब मैं खर्च किसी के खाते में डाल सकूं, तो मैं जोखिम के क्रम में काम करता हूं। बचत का मुफ्त हिस्सा शुद्ध बर्बादी है: बिना जुड़े volume, पुराने snapshot, बेकार पड़े load balancer, आठ घंटे काम करने वाली टीम के लिए चौबीस घंटे चलते development environment, और compliance के नब्बे दिन कहने के बावजूद हमेशा के लिए सेट log retention। अकेले इसी ने मुझे एक से ज्यादा बार लगभग मंजिल तक पहुंचाया है। इसके बाद किसी के दो साल पहले चुने आकार के बजाय असली utilization percentile के आधार पर right sizing, जो धीरे धीरे और निगरानी के साथ की जाती है। फिर commitment, यानी उस baseline के खिलाफ reserved capacity या savings plan जो साफ तौर पर कहीं नहीं जा रहा, जो किसी चीज को बदलने के बजाय एक वादे के बदले छूट है। उसके बाद ही मैं आर्किटेक्चर देखता हूं, जैसे data transfer के पैटर्न या ठंडे डेटा को सस्ते storage में ले जाना, और वे मालिक टीम के पास नंबरों वाले प्रस्ताव के रूप में जाते हैं। आखिरी हिस्सा दोबारा फिसलने से रोकना है: budget, anomaly alert, और लागत को उन्हीं dashboard पर दिखाना जहां reliability दिखती है।