एक इंफ्रास्ट्रक्चर इंजीनियर से SRE बनने के एक सप्ताह बाद

11 min

language: ja bn en es hi pt ru zh-cn zh-tw

नमस्ते, मैं अक्षम हूँ।
मैंने खुद भी काफी रिसर्च की थी, लेकिन SRE के रूप में काम करने वाले लोगों के रिकॉर्ड मुझे नौकरी शुरू करने से पहले ज्यादा नहीं मिले, जिससे मुझे कोई स्पष्ट विचार नहीं मिला, इसलिए मैं इसे यहाँ लिख रहा हूँ।
शुरुआत में, मैंने इसे एक इंटरमिशन के रूप में शामिल किया है, जो व्यावसायिक रूप से बहुत अधिक संबंधित नहीं है, ताकि अन्य व्यवसायों के लोग भी इसका आनंद ले सकें।

मैं ऐसा व्यक्ति हूँ

  • विंटेज स्टोर में 3 से 4 साल का अनुभव
  • इंफ्रास्ट्रक्चर इंजीनियर के रूप में 1 साल का अनुभव

मुझे मूल रूप से कंप्यूटर पसंद थे, इसलिए मैंने छठी कक्षा से रेंटल सर्वर पर वेबसाइटें बनाईं, मिडिल स्कूल से कस्टम-बिल्ट पीसी और सोल्डरिंग आयरन का उपयोग करके उनकी मरम्मत की, और सीजीआई किताबें सीखकर रेंटल सर्वर पर बुलेटिन बोर्ड स्थापित किए।

मैंने सूचना प्रौद्योगिकी में हाई स्कूल से स्नातक किया था, लेकिन उस समय सेंडाई में तथाकथित सूचना और संचार उद्योग और आईटी से संबंधित नौकरियों की कमी थी, और मुझे आश्चर्य था कि क्या मैं वास्तव में इसे एक पेशे के रूप में कर सकता हूँ, इसलिए मैं भटकता रहा।
अब, काम के कारण, मैं इस महीने से टोक्यो का निवासी बन गया हूँ।
मैंने एक विंटेज स्टोर में काम किया क्योंकि तत्कालीन अध्यक्ष ने मुझसे पूछा था कि क्या मैं काम करना चाहूँगा, और मैंने एक अंशकालिक कर्मचारी के रूप में शुरुआत की और बाद में एक पूर्णकालिक कर्मचारी बन गया।

परिचय: एक सप्ताह जो तेजी से बीत गया

मैं दूसरे प्रांत में चला गया और पिछले महीने 27 दिसंबर तक तेजी से काम कर रहा था, इसलिए मुझे अपने दिमाग को कई तरह से स्विच करने की आवश्यकता थी, और मैंने अपना सर्वश्रेष्ठ प्रदर्शन किया।
मुझे 23 साल की उम्र में यह अवसर मिला, इसलिए मैं पूरी गति से दौड़ रहा था।

मैंने बिना देखे घर का फैसला किया, लेकिन यह काम से कुछ दूरी पर है और घर के पास निम्नलिखित चीजें होना एक बड़ा फायदा है:

  • 100 येन स्टोर
  • सस्ता चीनी रेस्तरां
  • व्यक्तिगत रीसायकल शॉप

जब मैं घर पहुँचा, तो मुझे पता चला कि कोई सीलिंग लाइट नहीं थी, और मैं लगभग 1-2 दिनों तक बिना बिजली के रहा, लेकिन यह उतना मुश्किल नहीं था। दिन के उजाले में उठना और अंधेरे में सोना मेरे शरीर की घड़ी को रीसेट करने का एक शानदार तरीका है।

MacOS और Mac US लेआउट के साथ अपरिचित दिन

मैं वर्तमान में एक उत्साही GNU/Linux और BSD उपयोगकर्ता हूँ, लेकिन यह मेरे लिए चिंता का विषय था।
हालांकि, लीनस द्वारा भी प्रशंसित M1/2/3 चिप्स वाले मैक बहुत शक्तिशाली हैं।

यह मेरा पहला .zsh अनुभव था, लेकिन यह मूल रूप से bash का एक सुपरसेट है, इसलिए मुझे ज्यादा परेशानी नहीं हुई। हालांकि, डिफ़ॉल्ट $PS1, प्रॉम्प्ट डिस्प्ले न्यूनतम है और इसमें कोई रंग योजना सेटिंग्स नहीं हैं, इसलिए मैंने इसे अपने Artix Linux के अनुसार अनुकूलित किया।
Image

मैंने केवल न्यूनतम .vimrc सेटिंग्स कीं।

Mac US लेआउट!

कॉम्पैक्ट मैकबुक के JIS लेआउट में, कुंजियाँ बहुत अधिक संकुचित थीं, जिससे मुझे चिंता हुई, और half-width/full-width कुंजी मैकबुक के JIS लेआउट में एक ही स्थान पर मौजूद नहीं है, इसलिए मैंने US लेआउट का उपयोग किया, लेकिन JIS का उपयोग करने की आदत होने के कारण इसमें अभ्यस्त होना अभी भी मुश्किल है।
यह एक ऐसी समस्या है जिसे अंततः बाहरी कीबोर्ड का उपयोग करके हल किया जा सकता है, इसलिए यदि यह बाद में असहनीय हो जाता है तो इसे किसी भी तरह से प्रबंधित किया जा सकता है।

मैंने अपने पिछले ब्लॉग में कहा था कि मुझे एक ThinkPad कीबोर्ड खरीदना होगा... क्या वह एक मतिभ्रम था...?

कोई है जो Qiita पर एक लेख लिख रहा है जिसे मैंने देखा था...

जब कोई व्यक्ति जिसने Qiita पर लेख लिखे हैं, कंपनी में होता है, तो यह एकतरफा ऑफ़लाइन मीटिंग जैसा लगता है क्योंकि वे मुझे नहीं जानते, लेकिन मैंने उनके लेख पढ़े हैं।

Qiita के नाम की उत्पत्ति और आइकन की उत्पत्ति के बारे में सुनना दिलचस्प है, जिससे मुझे यह सोचने पर मजबूर होना पड़ता है कि क्या ऐसी पृष्ठभूमि थी।

ऑपरेशनल फ्लो, वर्क फ्लो, और अन्य

यह प्रत्येक संगठन के अनुसार भिन्न होता है, इसलिए मुझे चैट आदि में प्रवाह को समझना था, इसे विभिन्न भागों के रूप में पहचानना था, और इसे अपने दिमाग में कल्पना करके संयोजित करना था।

जैसे एक ही सॉफ्टवेयर का उपयोग अलग-अलग तरीकों से किया जा सकता है, जैसे Nginx एक वेब सर्वर और एक प्रॉक्सी सर्वर के रूप में कार्य कर सकता है, वैसे ही काम के संबंध में, मुझे यह कल्पना करने में कठिनाई हुई कि हर कोई अपने दैनिक कार्यों को किस प्रवाह में करता है। हालांकि, मेरे दयालु वरिष्ठों की बदौलत, मैं धीरे-धीरे इसे समझने में सक्षम हो रहा हूँ।
लोगों के प्रति कृतज्ञता और आभार।

हर दिन नोट्स लें

चूंकि मैं आमतौर पर vim का उपयोग करता हूँ, Markdown प्रारूप में नोट्स लेना बाद में दैनिक रिपोर्ट लिखते समय सुविधाजनक होता है, और कई बार ऐसा होता है जब तुच्छ नोट्स भी बाद में आवश्यक हो जाते हैं। इसलिए, यह तय करने के लिए कि क्या लिखना शुरू करें, मीटिंग के दौरान देखे गए URL को नोट्स में चिपकाना भी एक अच्छा विचार हो सकता है।

आंतरिक सुरक्षा के कारण, यदि आप केवल टर्मिनल से बिना प्रमाणीकरण के नहीं देख सकते हैं तो इसका कोई मतलब नहीं है, लेकिन मैंने जो टूल बनाया है जो URL से शीर्षक प्राप्त करता है और इसे Markdown प्रारूप में आउटपुट करता है, वह काम के दौरान उपयोगी रहा है, इसलिए मैं इसका प्रचार करूँगा।
GitHub - haturatu/ght: go-http-title Get website title

ईमानदारी से कहूँ तो, शुरुआत में करने के लिए कुछ खास नहीं है, लेकिन संगठन-व्यापी IaC के फायदे

हर दिन सीखने को मिलता है, इसलिए यह बहुत सुखद दिन हैं।
विशेष रूप से, इंफ्रास्ट्रक्चर इंजीनियरों से बड़ा अंतर यह है कि हम अधिक क्लाउड-जैसे संचालन की उम्मीद करते हैं, इसलिए समग्र वास्तुकला की कल्पना करना मुश्किल हो सकता है, लेकिन निश्चित रूप से, मूल अवधारणाएं कई बार उपयोगी होती हैं।
IaC को लागू करना मुश्किल हो सकता है, लेकिन केवल वेब GUI पर सभी आवश्यक जानकारी को एक-एक करके देखने के बजाय, कोड-प्रबंधित होने पर यह जानना आसान होता है कि कौन सा कॉन्फ़िगरेशन लॉन्च किया जाएगा, क्योंकि इसे टेक्स्ट-आधारित रूप से सत्यापित किया जा सकता है, जिसके कई फायदे हैं।

नुकसान क्या हैं?

मुझे लगता है कि इसमें कोई खास नुकसान नहीं है, लेकिन शुरुआत में ऑपरेशनल इमेज को समझना मुश्किल है, इसलिए मैं SRE टीम में बाद में शामिल होने वाले लोगों की मदद करने के लिए व्यावसायिक रूप से दस्तावेज़ों को पूरक करना चाहता हूँ।

जैसा कि Google के SRE दस्तावेज़ों में भी कहा गया है, एक छोटे, कुलीन बल के रूप में कार्य करने की सिफारिश की जाती है, लेकिन मुझे लगता है कि इससे टीम के सदस्यों का कार्यभार बढ़ सकता है, इसलिए दस्तावेज़ों को पूरी तरह से तैयार करना ऑपरेशनल रूप से काफी मुश्किल हो सकता है। इसलिए, मुझे लगता है कि यदि मैं अपने नोट्स और सीख को, जो मुझे कुछ भी नहीं पता होने पर लिखता हूँ, बाद में दस्तावेज़ों में बदल सकता हूँ, तो यह उन लोगों के लिए भी अनुकूल होगा जो 'पहली बार' आ रहे हैं।

दस्तावेज़ीकरण की आवश्यकता

यह बिंदु OpenBSD के दर्शन पर आधारित है।
OpenBSD - Wikipedia

लक्ष्य 'सही विचार' (correctness) और 'सक्रिय सुरक्षा' (proactive security) है। यह ओपन सोर्स और दस्तावेज़ीकरण पर जोर देने, और सॉफ्टवेयर लाइसेंस पर समझौता न करने के लिए भी जाना जाता है। चूंकि थियो डी राड का घर अल्बर्टा, कैलगरी में है, कनाडा, जहाँ क्रिप्टोग्राफी के निर्यात पर कोई प्रतिबंध नहीं है, को विकास का आधार बनाया गया है। लोगो और शुभंकर पफी द पफरफिश है।

Google के SRE दस्तावेज़ों में UNIX दर्शन के विचारों से, UNIX के वंशज BSD-आधारित दर्शन भी गलत नहीं होने चाहिए।

सबसे पहले, यदि कोई समझने वाला व्यक्ति नहीं है, तो निरंतर सुरक्षा सुनिश्चित करना मुश्किल है।

निष्कर्ष

मैंने यहाँ उन उत्पादों और सेवाओं का उल्लेख नहीं किया है जिनसे मैं वास्तव में काम में निपटता हूँ, क्योंकि सुरक्षा संबंधी विचार भी हैं, लेकिन 'यह ठीक हो जाएगा!' की भावना के साथ, यह ठीक हो जाएगा।
और यह 'ठीक हो रहा है' वाला हिस्सा मेरे वरिष्ठों की बदौलत है, इसलिए मैं इसे और बेहतर बनाना चाहता हूँ।

जैसे-जैसे हर दिन अधिक चीजें समझ में आती हैं, आप भविष्य में खुद को बेहतर ढंग से देख सकते हैं, इसलिए आइए धीरे-धीरे कड़ी मेहनत करें, चाहे वह शौक हो या कुछ और!


तो, आज के लिए बस इतना ही।
फिर मिलेंगे।

Related Posts