কিভাবে আমরা বার্নআউট প্রতিরোধ করার জন্য সর্বদা সংযুক্ত রাষ্ট্র পরিবর্তন করেছি

নিবন্ধটির অনুবাদটি কোর্সের শিক্ষার্থীদের জন্য বিশেষভাবে প্রস্তুত করা হয়েছিল "DevOps অনুশীলন এবং সরঞ্জাম".

ইন্টারকমের লক্ষ্য হল অনলাইন ব্যবসা ব্যক্তিগতকৃত করা। কিন্তু আপনি একটি পণ্য ব্যক্তিগতকৃত করতে পারবেন না যখন এটি কাজ করে না। কিভাবে. কর্মক্ষমতা আমাদের ব্যবসার সাফল্যের জন্য গুরুত্বপূর্ণ, শুধুমাত্র আমাদের ক্লায়েন্টরা আমাদের অর্থ প্রদানের কারণে নয়, আমরা নিজেরাই ব্যবহার করি। আপনার পণ্যের সাথে. যদি আমাদের পরিষেবা কাজ না করে, আমরা আক্ষরিক অর্থেই আমাদের গ্রাহকদের ব্যথা অনুভব করি।

মসৃণ অপারেশন অনেক কারণের উপর নির্ভর করে, যেমন সফ্টওয়্যার আর্কিটেকচার এবং দৈনন্দিন কাজের গুণমান। যাইহোক, প্রায়শই এটি এই সত্যে নেমে আসে যে যে ব্যক্তি সর্বদা যোগাযোগে থাকে সে কলের উত্তর দেয় PagerDuty. এই ধরনের প্রযুক্তিগত সহায়তা একটি শক্তিশালী গ্রাহক-কেন্দ্রিক টুল হতে পারে যা গ্রাহকরা আপনার পণ্য কেনার সময় যা পায় তার সাথে ইঞ্জিনিয়ারদের সাহায্যকে একত্রিত করে। এটি শেখার এবং বৃদ্ধির জন্য একটি দুর্দান্ত সুযোগ, কারণ সর্বোপরি, ব্যর্থতা এবং ভুলগুলি দক্ষতা অনুশীলন করার এবং জটিল কাজের প্রক্রিয়া বোঝার একটি ভাল সুযোগ হতে পারে।

কাজের সময়ের বাইরে "সর্বদা চালু" থাকা আপনার জীবনে ক্ষতিকর প্রভাব ফেলে।

কিন্তু একই সময়ে, "সর্বদা চালু" থাকা আপনার জীবনে ক্ষতিকর প্রভাব ফেলতে পারে। কিছু নষ্ট হয়ে গেছে এমন সতর্কতার জন্য আপনাকে দ্রুত এবং দক্ষতার সাথে প্রতিক্রিয়া জানাতে প্রস্তুত থাকতে হবে। এমনকি যদি আপনি যে কোনও মুহূর্তে পৃষ্ঠায় না থাকেন, "সর্বদা চালু" থাকা উদ্বেগ তৈরি করতে পারে, আমি ব্যক্তিগত অভিজ্ঞতা থেকে জানি। এই কারণে, ঘুমের গুণমান বিশেষ করে দৃঢ়ভাবে খারাপ হয়। নিয়মিতভাবে দিনের যে কোনো সময় অ্যাক্সেস জোনে থাকা বার্নআউট, উদাসীনতা বা, সাধারণভাবে, কম্পিউটারটি আর কখনও না দেখার আকাঙ্ক্ষার দিকে নিয়ে যেতে পারে।

ইন্টারকমে "সর্বদা সংযুক্ত" অবস্থার ইতিহাস

ইন্টারকমের একেবারে প্রথম দিকে, আমাদের টেকনিক্যাল ডিরেক্টর, সিয়ারান, এককভাবে XNUMX/XNUMX কারিগরি সহায়তার একটি সম্পূর্ণ দল, অফিসের ভিতরে এবং বাইরে উভয় ক্ষেত্রেই প্রদান করেছিলেন। ইন্টারকম বাড়ার সাথে সাথে সিয়ারানকে সাহায্য করার জন্য একটি টাস্ক ফোর্স তৈরি করা হয়েছিল। শীঘ্রই, নতুন উন্নয়ন দলগুলি অনেক নতুন বৈশিষ্ট্য এবং পরিষেবা তৈরি করতে শুরু করে এবং তারা সমস্ত প্রযুক্তিগত সহায়তার দায়িত্ব গ্রহণ করে।

যে কোন মুহূর্তে "অন কল" অনেক লোক ছিল।

সেই সময়ে, এই পদ্ধতিটি নো-ব্রেইনারের মতো মনে হয়েছিল কারণ এটি একটি মুহুর্তের নোটিশে আমাদের প্রযুক্তি সহায়তা দলকে স্কেল করার একটি সহজ উপায় ছিল, এটি আমাদের মানগুলির সাথে সামঞ্জস্যপূর্ণ ছিল এবং এটি আমাদের জন্য উপযুক্ত মালিকানার অনুভূতি. শেষ পর্যন্ত, কোন পরিকল্পনা ছাড়াই, আমরা চার বা পাঁচটি দলের সাথে শেষ করেছি যারা নিয়মিতভাবে ক্লায়েন্টদের সাথে তাদের অ-কাজের সময়গুলিতে যোগাযোগ করে। বাকি ডেভেলপমেন্ট টিমের অনেক জটিল সমস্যা ছিল না যা একটি ত্রুটি ছুঁড়তে পারে, তাই তাদের খুব কমই, যদি কখনও ডাকা হয়।

আমরা বুঝতে পেরেছি যে আমরা এমন একটি পরিস্থিতিতে ছিলাম যেখানে আমাদের কাছে প্রযুক্তিগত সহায়তা মেকানিক্স ছিল যা নিয়ে আমরা গর্ব করতে পারি না, এবং বেশ কয়েকটি জটিল সমস্যা যা আমরা সমাধান করতে চেয়েছিলাম, যেমন:

• যে কোনো সময়ে চ্যালেঞ্জ নিতে প্রস্তুত অনেক লোক ছিল। আমাদের অবকাঠামো এত বড় ছিল না যে নিয়মিত ছুটি ছাড়া কাজ করার জন্য ন্যূনতম পাঁচজন উন্নয়ন প্রকৌশলী প্রয়োজন।
• আমাদের অ্যালার্ম এবং কল পদ্ধতির গুণমান টিম জুড়ে সামঞ্জস্যপূর্ণ ছিল না, এবং আমরা নতুন এবং বিদ্যমান সমস্যা সতর্কতা পর্যালোচনা করার জন্য অ্যাডহক প্রক্রিয়া ব্যবহার করেছি। রানবুকের নির্দেশাবলী (কোন সমস্যা সম্পর্কে অবহিত হলে অনুসরণ করা হবে) বেশিরভাগই তাদের অনুপস্থিতির কারণে স্পষ্ট ছিল।
• ইঞ্জিনিয়াররা যে দলে কাজ করেছিল তার উপর নির্ভর করে, তাদের পরস্পরবিরোধী প্রত্যাশা ছিল। উদাহরণস্বরূপ, শুধুমাত্র প্রথম প্রযুক্তিগত সহায়তা দলের অন-কল শিফট এবং সপ্তাহান্তে ব্যাহত হওয়ার জন্য কোনো ক্ষতিপূরণ ছিল।
• বিজোড় সময়ে অপ্রয়োজনীয় কলের জন্য সহনশীলতার একটি সাধারণ স্তর বলে মনে হয়েছে।
• অবশেষে, এই ধরনের কাজ সবার জন্য নয়। জীবন পরিস্থিতি কখনও কখনও দেখায় যে ডিউটি ​​পরিবর্তন মানুষের উপর সর্বোত্তম প্রভাব ফেলে না।

সঠিক "সর্বদা চালু" অবস্থা খোঁজা

আমরা একটি নতুন ভার্চুয়াল টিম তৈরি করার সিদ্ধান্ত নিয়েছি যেটি অ-কাজের সময় প্রতিটি দলের জন্য প্রযুক্তিগত সহায়তার কাজ করবে৷ দলটি স্বেচ্ছাসেবকদের নিয়ে গঠিত হবে, সংগঠনের কোনো দলের সদস্য নয়। ভার্চুয়াল টিমের প্রকৌশলীরা প্রায় প্রতি ছয় মাসে ঘুরতেন, সপ্তাহ "কলে" কাটান। ভাগ্যক্রমে, একটি ভার্চুয়াল দল একত্রিত করার জন্য পর্যাপ্ত স্বেচ্ছাসেবক খুঁজে পেতে আমাদের কোন সমস্যা হয়নি।

ফলস্বরূপ, আমাদের সহায়তা দল 30 জনের থেকে কমিয়ে 6 বা 7 জনে নেমে এসেছে।

দলটি তখন সম্মত হয়েছে এবং সংজ্ঞায়িত করেছে যে কোন সমস্যা সতর্কতা এবং বিবরণ রানবুকে কেমন হওয়া উচিত, এবং নতুন সমর্থন দলে সতর্কতা ফরোয়ার্ড করার একটি প্রক্রিয়া বর্ণনা করেছে। তারা একটি টেরাফর্ম মডিউল ব্যবহার করে কোডে সমস্ত সতর্কতা সংজ্ঞায়িত করেছে এবং প্রতিটি পরিবর্তনের জন্য পিয়ার পর্যালোচনা ব্যবহার করা শুরু করেছে। আমরা একটি সাপ্তাহিক শিফটের জন্য ক্ষতিপূরণের একটি স্তর প্রবর্তন করেছি যা কর্তব্যরত কর্মকর্তাদের কাছে বেশ সন্তোষজনক ছিল। আমরা একটি দ্বিতীয়-স্তরের বর্ধিত দলও তৈরি করেছি যা শুধুমাত্র পরিচালকদের নিয়ে গঠিত। এই দলটি প্রযুক্তিগত সহায়তা প্রকৌশলীদের জন্য বৃদ্ধির একক পয়েন্ট হওয়া উচিত।

আমাদের বেশ কয়েক মাস কঠোর পরিশ্রম ছিল, যে সময়ে আমরা এই প্রক্রিয়াটি প্রতিষ্ঠা করেছি; ফলস্বরূপ, এখন আগের মতো 30 জন প্রকৌশলী কলে ছিল না, তবে মাত্র 6 বা 7 জন। কর্মঘণ্টা চলাকালীন, দলগুলি স্বাধীনভাবে তাদের কার্যাবলী বা সমস্যাগুলির সাথে মোকাবিলা করে পরিষেবাগুলি, অন এই সময়ে যখন সবচেয়ে বেশি সংখ্যক ব্রেকডাউন সাধারণত ঘটে, তবে অন্য সব সময়ে, স্বেচ্ছাসেবকদের দ্বারা প্রযুক্তিগত সহায়তা প্রদান করা হয়।

আমরা যা শিখেছি

আমরা আমাদের ভার্চুয়াল টেকনিক্যাল সাপোর্ট টিম চালু করার পর, আমরা নতুন কাজের প্রবাহ আশা করছি, যেমন সমস্যার কারণ অনুসন্ধান করা বা বিভ্রাটের কারণ হওয়া একটি সমস্যা সমাধানের জন্য একত্রিত হওয়া। যাইহোক, আমাদের উন্নয়ন দলগুলি ব্যর্থতার কারণগুলির জন্য সম্পূর্ণ দায়বদ্ধতা নিয়েছিল এবং পরবর্তী যে কোনও প্রতিক্রিয়া সাধারণত তাত্ক্ষণিক ছিল৷ আমাদের এমন একটি পরিস্থিতি এড়াতেও দরকার ছিল যেখানে একটি প্রযুক্তিগত পরামর্শের কাজটি যে দল থেকে এসেছিল তার কাছে ফেরত পাঠানো হবে, যাতে ইঞ্জিনিয়ারদের ঘণ্টার পর ঘণ্টা যোগাযোগ করতে বাধ্য না করা হয়।

আফটার আওয়ার কলের সংখ্যা প্রতি মাসে 10-এর কম হয়েছে।

আমাদের বৃদ্ধি প্রক্রিয়া খুব কমই আনুষ্ঠানিকভাবে ব্যবহৃত হয়েছিল। একটি আরও সাধারণ বিশ্বাস ছিল যে ইঞ্জিনিয়ারকে অনানুষ্ঠানিকভাবে সাহায্য করা হয়েছিল যে দলটি বর্তমানে অনলাইনে ছিল, বিশেষ করে সান ফ্রান্সিসকো অফিসে আমাদের ছেলেরা। টিমওয়ার্ক এবং ফ্লাইতে তাদের সমাধানের মাধ্যমে অনেক সমস্যা দূর করা হয়েছে বা হ্রাস করা হয়েছে।

আমাদের সান ফ্রান্সিসকো অফিসের প্রকৌশলীরা পূর্ণ-সময়ে দলে যোগ দিয়েছিলেন এবং সাধারণ প্রযুক্তিগত সহায়তার বাইরে চলে গিয়েছিলেন। আমরা কিছু ওভারহেড খরচের সম্মুখীন হয়েছিলাম, কিন্তু একাধিক অফিসে আমাদের সমর্থন দলের সদস্যতা ছড়িয়ে দেওয়া আমাদের সুবিধার জন্য কাজ করেছে কারণ এটি সম্পর্ক তৈরি করার, তাদের শক্তিশালী করার এবং আমরা সবাই যে প্রযুক্তি স্ট্যাক নিয়ে কাজ করি সে সম্পর্কে আরও শিখতে এটি একটি ভাল উপায় বলে প্রমাণিত হয়েছে।

ইন্টারকম ডেভেলপারদের কাজ আমাদের দলগুলিতে আরও সামঞ্জস্যপূর্ণ হয়ে উঠেছে, এবং আমরা আমাদের সাইটে সিস্টেম ইঞ্জিনিয়ার হওয়ার সুবিধাগুলি সম্পর্কে আত্মবিশ্বাসের সাথে কথা বলতে পারি কেরিয়ার, উল্লেখ করে যে আপনি হতে না চাইলে সবসময় সংযুক্ত থাকার প্রয়োজন নেই।

আমাদের ডেটা স্টোরগুলিকে স্থিতিশীল এবং স্কেল করার জন্য মৌলিক কাজের পাশাপাশি, সমস্যা সমাধানের উপর ক্রমাগত ফোকাস করার ফলে প্রতিমাসে 10-এরও কম ঘন্টার কলের সংখ্যা কমেছে। আমরা এই সংখ্যার জন্য খুব গর্বিত।

আমরা আমাদের প্রযুক্তিগত সহায়তা টিম বজায় রাখা এবং উন্নত করার জন্য কাজ চালিয়ে যাচ্ছি, এবং ইন্টারকম বাড়ার সাথে সাথে আমাদের সিদ্ধান্তগুলি পুনর্বিবেচনা করতে হতে পারে, কারণ আজ যা কাজ করে তা পরের বার আমাদের কর্মীরা দ্বিগুণ হয়ে গেলে অবশ্যই কাজ করবে না। যাইহোক, এই অভিজ্ঞতা আমাদের প্রতিষ্ঠানের জন্য অত্যন্ত ইতিবাচক এবং আমাদের ডেভেলপমেন্ট ইঞ্জিনিয়ারদের জীবনযাত্রার মান, কলে আমাদের প্রতিক্রিয়ার মান এবং সর্বোপরি, আমাদের গ্রাহকদের অভিজ্ঞতার ব্যাপক উন্নতি করেছে।

উত্স: www.habr.com