DevOps ট্রান্সফরমেশনের সাতটি আর্কিটাইপ

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

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

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

স্পিকার সম্পর্কে:

আইটি ম্যানেজমেন্টে 35 বছরেরও বেশি সময় ধরে, ক্যানোনিকাল-এ ওপেনক্লাউডের পূর্বসূরি তৈরিতে অংশ নিয়েছিল, 10টি স্টার্টআপে অংশ নিয়েছিল, যার মধ্যে দুটি ডেল এবং ডকারের কাছে বিক্রি হয়েছিল। বর্তমানে তিনি SJ Technologies-এ DevOps এবং ডিজিটাল অনুশীলনের ভাইস প্রেসিডেন্ট।

এর পরের ঘটনাটি জনের দৃষ্টিকোণ থেকে।

আমার নাম জন উইলিস এবং আমাকে খুঁজে পাওয়ার সবচেয়ে সহজ জায়গা হল টুইটার, @বটচাগালুপে. জিমেইল এবং গিটহাবে আমার একই উপনাম আছে। ক এই লিঙ্ক দ্বারা আপনি তাদের জন্য আমার প্রতিবেদন এবং উপস্থাপনা ভিডিও রেকর্ডিং খুঁজে পেতে পারেন.

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

DevOps কি?

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

এখন আমাদের কাছে প্রচুর ডেটা আছে, পাঁচ বছরের একাডেমিক গবেষণা, শিল্প স্কেলে তত্ত্বের পরীক্ষা। এই গবেষণাগুলি আমাদের যা বলে তা হল যে আপনি যদি একটি সাংগঠনিক সংস্কৃতিতে কিছু আচরণগত নিদর্শনগুলিকে একত্রিত করেন তবে আপনি 2000x গতি অর্জন করতে পারেন। এই ত্বরণ স্থিতিশীলতার সমান উন্নতির দ্বারা মেলে। এটি একটি পরিমাণগত পরিমাপ যে সুবিধাটি DevOps যেকোনো কোম্পানিতে আনতে পারে। কয়েক বছর আগে, আমি একটি Fortune 5000 কোম্পানির CEO-এর সাথে DevOps সম্পর্কে কথা বলছিলাম৷ আমি যখন উপস্থাপনার জন্য প্রস্তুতি নিচ্ছিলাম, তখন আমি খুব নার্ভাস ছিলাম কারণ আমাকে আমার বছরের অভিজ্ঞতা 5 মিনিটে সংক্ষিপ্ত করতে হয়েছিল৷

শেষে নিচে দিলাম DevOps এর সংজ্ঞা: এটি এমন একটি চর্চা এবং নিদর্শন যা মানব পুঁজিকে উচ্চ-কার্যকারিতা সাংগঠনিক পুঁজিতে রূপান্তর করতে সক্ষম করে। একটি উদাহরণ হল টয়োটা গত 50 বা 60 বছর ধরে যেভাবে কাজ করেছে।

(এরপরে, এই জাতীয় চিত্রগুলি রেফারেন্স উপাদান হিসাবে নয়, বরং চিত্র হিসাবে দেওয়া হয়েছে। প্রতিটি নতুন কোম্পানির জন্য তাদের বিষয়বস্তু আলাদা হবে। তবে, ছবিটি আলাদাভাবে দেখা এবং বড় করা যেতে পারে। এই লিঙ্কে।)

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

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

খারাপ সংস্কৃতি প্রাতঃরাশের জন্য ভাল পন্থা খায়

মূল ধারণাটি হল: সংস্থার সংস্কৃতি নিজেই খারাপ হলে Lean, Agile, SAFE এবং DevOps-এর কোনো পরিমাণ সাহায্য করবে না। এটি স্কুবা গিয়ার ছাড়া গভীরতায় ডুব দেওয়ার মতো বা এক্স-রে ছাড়াই কাজ করার মতো। অন্য কথায়, ড্রাকার এবং ডেমিংকে ব্যাখ্যা করার জন্য: একটি খারাপ সাংগঠনিক সংস্কৃতি যে কোনও ভাল সিস্টেমকে শ্বাসরোধ না করেই গ্রাস করবে।

এই প্রধান সমস্যা সমাধানের জন্য, আপনাকে নিম্নলিখিত পদক্ষেপগুলি গ্রহণ করতে হবে:

1. সমস্ত কাজ দৃশ্যমান করুন: আপনাকে সমস্ত কাজ দৃশ্যমান করতে হবে। এই অর্থে নয় যে এটি অবশ্যই কিছু স্ক্রিনে প্রদর্শিত হবে, তবে এই অর্থে যে এটি অবশ্যই পর্যবেক্ষণযোগ্য হতে হবে।
2. একত্রিত কাজ ব্যবস্থাপনা সিস্টেম: ব্যবস্থাপনা সিস্টেম একত্রিত করা প্রয়োজন. "উপজাতীয়" জ্ঞান এবং প্রাতিষ্ঠানিক জ্ঞানের সমস্যায়, 9টির মধ্যে 10টি ক্ষেত্রে বাধা হয়ে দাঁড়ায় মানুষ। বইয়ে "ফিনিক্স প্রকল্প" সমস্যাটি ছিল একজন একক ব্যক্তির সাথে, ব্রেন্ট, যার কারণে প্রকল্পটি নির্ধারিত সময়ের তিন বছর পিছিয়ে ছিল। এবং আমি এই "ব্রেন্টস" সব জায়গায় দৌড়াচ্ছি। এই বাধাগুলি সমাধান করতে, আমি আমাদের তালিকার পরবর্তী দুটি আইটেম ব্যবহার করি।
3. সীমাবদ্ধতা পদ্ধতির তত্ত্ব: সীমাবদ্ধতার তত্ত্ব.
4. সহযোগিতা হ্যাক: সহযোগিতা হ্যাক।
5. টয়োটা কাটা (কোচিং কাটা): আমি টয়োটা কাতা সম্পর্কে বেশি কথা বলব না। আগ্রহী হলে, আমার গিথুবে উপস্থাপনা আছে এই বিষয়ে প্রায় প্রতিটি এক.
6. বাজার ভিত্তিক সংগঠন: বাজার ভিত্তিক সংগঠন।
7. শিফট-বাম নিরীক্ষক: চক্রের প্রাথমিক পর্যায়ে নিরীক্ষা।

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

(এই চিত্রটি আলাদাভাবে দেখা যেতে পারে লিঙ্ক দেখুন)

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

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

(এই চিত্রটি আলাদাভাবে দেখা যেতে পারে লিঙ্ক দেখুন)

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

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

(এই চিত্রটি আলাদাভাবে দেখা যেতে পারে লিঙ্ক দেখুন)

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

(এই চিত্রটি আলাদাভাবে দেখা যেতে পারে লিঙ্ক দেখুন)

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

আমাদের সভা অত্যন্ত বিভ্রান্তিকর পদ্ধতিতে এগিয়েছিল: প্রায় তিন ঘন্টা ধরে, পাঁচটি ভিন্ন দল আমাকে ব্যাখ্যা করতে পারেনি যে কোড এবং সমাবেশের মধ্যে কী ঘটছে। এবং এই সহজ জিনিস বলে মনে হবে. বেশিরভাগ DevOps পরামর্শদাতারা সামনে ধরে নেন যে সবাই এটি ইতিমধ্যেই জানেন।

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

(এই চিত্রটি আলাদাভাবে দেখা যেতে পারে লিঙ্ক দেখুন)

বিনিয়োগ সফটওয়্যার টিমের সাথে এই ব্যাংকে সর্বশেষ বৈঠক হয়েছিল। এটি তার সাথেই প্রমাণিত হয়েছিল যে কাগজের শীটে মার্কার দিয়ে ডায়াগ্রাম লেখা বোর্ডের চেয়ে ভাল এবং স্মার্টবোর্ডের চেয়েও ভাল।

আমাদের মিটিংয়ের চতুর্থ দিনে হোটেলের কনফারেন্স রুমটি কেমন ছিল তা আপনি দেখতে পাচ্ছেন। এবং আমরা এই স্কিমগুলি ব্যবহার করে নিদর্শনগুলি অনুসন্ধান করতে, অর্থাৎ, আর্কিটাইপস।

তাই, আমি কর্মীদের প্রশ্ন করি, তারা তিনটি রঙের (কালো, লাল এবং নীল) মার্কার দিয়ে উত্তরগুলি লিখে দেয়। আমি archetypes জন্য তাদের উত্তর বিশ্লেষণ. এখন ক্রমানুসারে সব প্রত্নতত্ত্ব আলোচনা করা যাক।

1. সমস্ত কাজ দৃশ্যমান করুন: কাজ দৃশ্যমান করুন

আমি যাদের সাথে কাজ করি তাদের বেশিরভাগ কোম্পানির অজানা কাজের খুব বেশি শতাংশ রয়েছে। উদাহরণস্বরূপ, এটি যখন একজন কর্মচারী অন্যের কাছে আসে এবং কেবল কিছু করতে বলে। বড় প্রতিষ্ঠানে, 60% অপরিকল্পিত কাজ হতে পারে। এবং 40% পর্যন্ত কাজ কোনোভাবেই নথিভুক্ত করা হয় না। যদি বোয়িং হতো, আমি জীবনে আর কখনো তাদের বিমানে চড়তাম না। যদি মাত্র অর্ধেক কাজ নথিভুক্ত করা হয়, তবে এই কাজটি সঠিকভাবে হচ্ছে কি না তা জানা যায় না। অন্যান্য সমস্ত পদ্ধতি অকেজো হয়ে উঠেছে - কোনও কিছু স্বয়ংক্রিয় করার চেষ্টা করার কোনও মানে নেই, কারণ পরিচিত 50% কাজের সবচেয়ে সুসংগত এবং স্পষ্ট অংশ হতে পারে, যার অটোমেশন দুর্দান্ত ফলাফল দেবে না এবং সমস্ত খারাপ জিনিস অদৃশ্য অর্ধেক হয়. ডকুমেন্টেশনের অনুপস্থিতিতে, সমস্ত ধরণের হ্যাক এবং লুকানো কাজ খুঁজে পাওয়া অসম্ভব, বাধাগুলি খুঁজে না পাওয়া, সেই "ব্রেন্টস" যা আমি ইতিমধ্যেই বলেছি। Dominica DeGrandis এর একটি চমৎকার বই আছে "কাজ দৃশ্যমান করা". সে প্রকাশ করে পাঁচটি ভিন্ন "সময় ফাঁস" (সময়ের চোর):

• প্রক্রিয়ায় খুব বেশি কাজ (WIP)
• অজানা নির্ভরতা
• অপরিকল্পিত কাজ
• পরস্পরবিরোধী অগ্রাধিকার
• অবহেলিত কাজ

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

ফিনিক্স প্রকল্প একটি প্রকল্প সম্পর্কে একটি বিস্ময়কর গল্প যা তিন বছর দেরী ছিল। একটি চরিত্র এই কারণে বরখাস্তের মুখোমুখি হয় এবং সে অন্য একটি চরিত্রের সাথে দেখা করে যাকে এক ধরণের সক্রেটিস হিসাবে উপস্থাপন করা হয়। তিনি ঠিক কি ভুল হয়েছে তা বের করতে সাহায্য করেন। দেখা যাচ্ছে যে কোম্পানির একজন সিস্টেম অ্যাডমিনিস্ট্রেটর রয়েছে, যার নাম ব্রেন্ট, এবং সমস্ত কাজ কোনও না কোনওভাবে তার মাধ্যমে চলে। একটি মিটিংয়ে, অধস্তনদের একজনকে জিজ্ঞাসা করা হয়: প্রতিটি আধঘণ্টার টাস্কে এক সপ্তাহ সময় লাগে কেন? উত্তরটি হল সারিবদ্ধ তত্ত্ব এবং লিটলস আইনের একটি খুব সরলীকৃত উপস্থাপনা, এবং এই উপস্থাপনায় দেখা যাচ্ছে যে 90% দখলে, প্রতিটি কাজের জন্য 9 ঘন্টা সময় লাগে। প্রতিটি টাস্ক অন্য সাতজনকে পাঠাতে হবে, যাতে সেই ঘন্টা 63 ঘন্টা হয়ে যায়, 7 গুণ 9। আমি যে পয়েন্টটি তৈরি করছি তা হল লিটলস ল বা যেকোন জটিল সারিবদ্ধ তত্ত্ব ব্যবহার করার জন্য, আপনার অন্তত ডেটা থাকা দরকার।

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

যখন কাজটি দৃশ্যমান হয়, তখন ডেটা সুন্দরভাবে শ্রেণীবদ্ধ করা যেতে পারে (যেটি ডমিনিকা ফটোতে করছে), পাঁচবারের ফাঁসের বিমূর্ততা প্রয়োগ করা যেতে পারে এবং অটোমেশন প্রয়োগ করা যেতে পারে।

2. ওয়ার্ক ম্যানেজমেন্ট সিস্টেম একত্রিত করুন: টাস্ক ম্যানেজমেন্ট

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

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

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

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

পরিষেবা পাইপলাইন

এটি আবার শুধুমাত্র বড় কর্পোরেশনের ক্ষেত্রে প্রযোজ্য। আপনি যদি একটি নতুন ক্ষেত্রে একটি নতুন কোম্পানি হন, আপনার হাতা গুটান এবং আপনার Travis CI বা CircleCI এর সাথে কাজ করুন। যখন ফরচুন 5000 কোম্পানির কথা আসে, আমি যেখানে কাজ করতাম সেই ব্যাঙ্কে ঘটেছিল এমন একটি ঘটনা। গুগল তাদের কাছে এসেছিল এবং তাদের পুরানো আইবিএম সিস্টেমের ডায়াগ্রাম দেখানো হয়েছিল। গুগলের ছেলেরা বিভ্রান্তিতে জিজ্ঞাসা করল - এর সোর্স কোড কোথায়? কিন্তু কোন সোর্স কোড নেই, এমনকি একটি GUIও নেই। এটি এমন বাস্তবতা যা বড় সংস্থাগুলিকে মোকাবেলা করতে হবে: একটি প্রাচীন মেইনফ্রেমে 40 বছরের পুরনো ব্যাঙ্ক রেকর্ড। আমার ক্লায়েন্টদের মধ্যে একজন সার্কিট ব্রেকার প্যাটার্ন সহ কুবারনেটেস কন্টেনার ব্যবহার করে, সাথে ক্যাওস মাঙ্কি, সমস্ত কীব্যাঙ্ক অ্যাপ্লিকেশনের জন্য। কিন্তু এই কন্টেইনারগুলি শেষ পর্যন্ত একটি COBOL অ্যাপ্লিকেশনের সাথে সংযুক্ত হয়।

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

3. সীমাবদ্ধতার তত্ত্ব: সীমাবদ্ধতার তত্ত্ব

আসুন তৃতীয় আর্কিটাইপের দিকে এগিয়ে যাই: প্রাতিষ্ঠানিক/"উপজাতি" জ্ঞান। একটি নিয়ম হিসাবে, যে কোনও সংস্থায় এমন বেশ কিছু লোক রয়েছে যারা সবকিছু জানে এবং সবকিছু পরিচালনা করে। এই তারাই যারা সংগঠনে সবচেয়ে বেশি সময় ধরে আছেন এবং যারা সব সমাধান জানেন।

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

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

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

4. কোলাবরেশন হ্যাকস: কোলাবরেশন হ্যাকস

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

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

5. কোচিং কাটা

আমি প্রথম দিকে সতর্ক করেছিলাম, আমি আজ এই বিষয়ে কথা বলব না। আপনি আগ্রহী হলে, আপনি একটি কটাক্ষপাত করতে পারেন আমার কিছু উপস্থাপনা.

মাইক রথার থেকে এই বিষয়ে একটি ভাল কথাও রয়েছে:

6. বাজারমুখী: বাজারমুখী সংগঠন

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

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

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

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

7. শিফট-বাম নিরীক্ষক: চক্রের প্রথম দিকে অডিট করুন। প্রদর্শনে নিরাপত্তা নিয়ম মেনে চলা

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

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

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

অনুযায়ী রিপোর্ট, সোনাটাইপ দ্বারা 2018 সালে তৈরি, 2017 সালে 87 বিলিয়ন OSS ডাউনলোডের অনুরোধ ছিল।

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

এই ক্রমটির একটি উদাহরণ:


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

এবং এমন কোন কারণ নেই যে আমরা নিরাপত্তার ক্ষেত্রে একই পন্থা নিতে পারিনি।

ফলাফল

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

দরকারী লিঙ্ক

এখানে DevOops কনফারেন্সের কয়েকটি আলোচনা রয়েছে যা আপনার কাজে লাগতে পারে:

• সের্গেই বার্দনিকভ, আর্টিওম কালিচকিন - সাফল্যের গল্প, বা "দেব+দেবঅপস+অপস" (видео, প্রতিবেদনের প্রতিলিপি)
• বারুচ সদোগুরস্কি, লিওনিড ইগোলনিক - একটি স্কেলে DevOps: একটি গ্রীক ট্র্যাজেডি ইন তিনটি অ্যাক্ট (видео, প্রতিবেদনের প্রতিলিপি)
• আলেকজান্ডার টিটোভ, কিরিল তোলকাচেভ - DevOps, প্রকৌশলী এবং সম্প্রদায়
• টিমোথি লিস্টার - চরিত্র, সম্প্রদায় এবং সংস্কৃতি: সমৃদ্ধির জন্য গুরুত্বপূর্ণ কারণ

মধ্যে দেখুন প্রোগ্রাম DevOops 2020 মস্কো — সেখানেও অনেক মজার জিনিস আছে।

উত্স: www.habr.com