DevOps સિદ્ધાંતો પર આધારિત સાત ટ્રાન્સફોર્મેશન આર્કીટાઇપ્સ

"ડેવોપ્સને કેવી રીતે અમલમાં મૂકવું" એ પ્રશ્ન વર્ષોથી છે, પરંતુ ત્યાં ઘણી સારી સામગ્રી નથી. કેટલીકવાર તમે બિન-સ્માર્ટ સલાહકારોની જાહેરાતોનો ભોગ બનો છો જેમને તેમનો સમય વેચવાની જરૂર હોય છે, પછી ભલે તે ગમે તે હોય. કેટલીકવાર આ અસ્પષ્ટ, અત્યંત સામાન્ય શબ્દો છે કે કેવી રીતે મેગાકોર્પોરેશનના જહાજો બ્રહ્માંડના વિસ્તરણને ખેડતા હોય છે. પ્રશ્ન ઊભો થાય છે: આ આપણને શું વાંધો છે? પ્રિય લેખક, શું તમે તમારા વિચારોને સૂચિમાં સ્પષ્ટપણે ઘડી શકો છો?

આ બધું એ હકીકતથી ઉદ્દભવે છે કે કંપનીની સંસ્કૃતિના પરિવર્તનના પરિણામોની વાસ્તવિક પ્રેક્ટિસ અને સમજણ એકઠી થઈ નથી. સંસ્કૃતિમાં પરિવર્તન એ લાંબા ગાળાની વસ્તુઓ છે, જેના પરિણામો એક અઠવાડિયા કે એક મહિનામાં દેખાશે નહીં. વર્ષોથી કંપનીઓ કેવી રીતે બનાવવામાં આવી છે અને નિષ્ફળ રહી છે તે જોવા માટે અમને પર્યાપ્ત વૃદ્ધ વ્યક્તિની જરૂર છે.

જ્હોન વિલિસ - DevOps ના પિતાઓમાંના એક. જોન પાસે મોટી સંખ્યામાં કંપનીઓ સાથે કામ કરવાનો દાયકાઓનો અનુભવ છે. તાજેતરમાં, જ્હોને ચોક્કસ પેટર્નની નોંધ લેવાનું શરૂ કર્યું જે તે દરેક સાથે કામ કરતી વખતે થાય છે. આ આર્કીટાઇપ્સનો ઉપયોગ કરીને, જ્હોન કંપનીઓને DevOps પરિવર્તનના સાચા માર્ગ પર માર્ગદર્શન આપે છે. DevOops 2018 કોન્ફરન્સમાંથી તેના અહેવાલના અનુવાદમાં આ આર્કીટાઇપ્સ વિશે વધુ વાંચો.

વક્તા વિશે:

આઇટી મેનેજમેન્ટમાં 35 વર્ષથી વધુ, કેનોનિકલમાં ઓપનક્લાઉડના પુરોગામીની રચનામાં ભાગ લીધો, 10 સ્ટાર્ટઅપ્સમાં ભાગ લીધો, જેમાંથી બે ડેલ અને ડોકરને વેચવામાં આવ્યા. હાલમાં તેઓ SJ Technologies ખાતે DevOps અને ડિજિટલ પ્રેક્ટિસના વાઇસ પ્રેસિડેન્ટ છે.

આગળ જ્હોનના દૃષ્ટિકોણથી વાર્તા છે.

મારું નામ જ્હોન વિલિસ છે અને મને શોધવાનું સૌથી સરળ સ્થળ Twitter પર છે, @botchagalupe. મારી પાસે Gmail અને GitHub પર સમાન ઉપનામ છે. એ по этой ссылке તમે તેમના માટે મારા અહેવાલો અને પ્રસ્તુતિઓના વિડિયો રેકોર્ડિંગ્સ શોધી શકો છો.

વિવિધ મોટી કંપનીઓના CIO સાથે મારી ઘણી બેઠકો છે. તેઓ વારંવાર ફરિયાદ કરે છે કે તેઓ સમજી શકતા નથી કે DevOps શું છે, અને દરેક વ્યક્તિ જે તેમને સમજાવવાનો પ્રયાસ કરે છે તે કંઈક અલગ વિશે વાત કરે છે. બીજી સામાન્ય ફરિયાદ એ છે કે DevOps કામ કરતું નથી, જો કે એવું લાગે છે કે નિર્દેશકો તેમને સમજાવ્યા પ્રમાણે બધું કરી રહ્યા છે. અમે મોટી કંપનીઓ વિશે વાત કરી રહ્યા છીએ જે સો વર્ષથી વધુ જૂની છે. તેમની સાથે વાત કર્યા પછી, હું નિષ્કર્ષ પર આવ્યો કે ઘણી સમસ્યાઓ માટે, તે ઉચ્ચ તકનીક નથી જે શ્રેષ્ઠ અનુકૂળ છે, પરંતુ પ્રમાણમાં ઓછી તકનીકી ઉકેલો છે. અઠવાડિયા સુધી મેં જુદા જુદા વિભાગના લોકો સાથે વાત કરી. તમે પોસ્ટમાં પ્રથમ ચિત્રમાં જે જુઓ છો તે મારો છેલ્લો પ્રોજેક્ટ છે, ત્રણ દિવસના કામ પછી આ રૂમ કેવો દેખાતો હતો.

DevOps શું છે?

ખરેખર, જો તમે 10 જુદા જુદા લોકોને પૂછો, તો તેઓ 10 અલગ અલગ જવાબો આપશે. પરંતુ અહીં રસપ્રદ વાત એ છે કે આ તમામ દસ જવાબો સાચા હશે. અહીં કોઈ ખોટો જવાબ નથી. હું લગભગ 10 વર્ષથી DevOps માં ખૂબ જ ઊંડો હતો, અને પ્રથમ DevOpsDay પર પ્રથમ અમેરિકન હતો. હું એમ નહીં કહું કે હું DevOpsમાં સામેલ દરેક કરતાં હોંશિયાર છું, પરંતુ ભાગ્યે જ કોઈએ તેના પર આટલો પ્રયત્ન કર્યો હોય. હું માનું છું કે DevOps ત્યારે થાય છે જ્યારે માનવ મૂડી અને ટેકનોલોજી એક સાથે આવે છે. આપણે ઘણી વાર માનવીય પરિમાણ વિશે ભૂલી જઈએ છીએ, જો કે આપણે તમામ પ્રકારની સંસ્કૃતિઓ વિશે ઘણી વાતો કરીએ છીએ.

હવે અમારી પાસે ઘણો ડેટા છે, પાંચ વર્ષનું શૈક્ષણિક સંશોધન, ઔદ્યોગિક ધોરણે સિદ્ધાંતોનું પરીક્ષણ. આ અભ્યાસો અમને જે કહે છે તે એ છે કે જો તમે સંસ્થાકીય સંસ્કૃતિમાં કેટલીક વર્તણૂકીય પેટર્નને જોડો છો, તો તમે 2000x ઝડપ હાંસલ કરી શકો છો. આ પ્રવેગક સ્થિરતામાં સમાન સુધારણા દ્વારા મેળ ખાય છે. આ લાભનું માત્રાત્મક માપ છે જે DevOps કોઈપણ કંપનીને લાવી શકે છે. થોડા વર્ષો પહેલા, હું એક Fortune 5000 કંપનીના CEO સાથે DevOps વિશે વાત કરી રહ્યો હતો. જ્યારે હું પ્રેઝન્ટેશનની તૈયારી કરી રહ્યો હતો, ત્યારે હું ખૂબ જ નર્વસ હતો કારણ કે મારે મારા વર્ષોના અનુભવનો 5 મિનિટમાં સારાંશ આપવાનો હતો.

અંતે મેં નીચે મુજબ આપ્યું DevOps ની વ્યાખ્યા: તે પ્રથાઓ અને પેટર્નનો સમૂહ છે જે માનવ મૂડીને ઉચ્ચ-પ્રદર્શન સંસ્થાકીય મૂડીમાં રૂપાંતરિત કરવા સક્ષમ બનાવે છે. ટોયોટા જે રીતે છેલ્લા 50 કે 60 વર્ષથી ઓપરેટ કરે છે તેનું ઉદાહરણ છે.

(ત્યારબાદ, આવા આકૃતિઓ સંદર્ભ સામગ્રી તરીકે નહીં, પરંતુ ચિત્ર તરીકે આપવામાં આવે છે. દરેક નવી કંપની માટે તેમની સામગ્રી અલગ-અલગ હશે. જો કે, ચિત્રને અલગથી જોઈ શકાય છે અને મોટું કરી શકાય છે. આ લિંક પર.)

સૌથી સફળ આવી પ્રથાઓમાંની એક છે મૂલ્ય પ્રવાહ મેપિંગ. આ વિશે ઘણા સારા પુસ્તકો લખવામાં આવ્યા છે, જેમાંથી સૌથી સફળ કેરેન માર્ટિનના છે. પરંતુ છેલ્લા એક વર્ષમાં, હું આ નિષ્કર્ષ પર આવ્યો છું કે આ અભિગમ પણ ખૂબ જ ઉચ્ચ તકનીકી છે. તેના ચોક્કસપણે ઘણા ફાયદા છે અને મેં તેનો ઘણો ઉપયોગ કર્યો છે. પરંતુ જ્યારે CEO તમને પૂછે કે શા માટે તેમની કંપની નવી રેલ્સ પર સ્વિચ કરી શકતી નથી, ત્યારે વેલ્યુ સ્ટ્રીમ મેપિંગ વિશે વાત કરવી ખૂબ જ વહેલું છે. ત્યાં ઘણા વધુ મૂળભૂત પ્રશ્નો છે જેનો જવાબ પહેલા આપવો જોઈએ.

મને લાગે છે કે મારા ઘણા સાથીદારો જે ભૂલ કરે છે તે એ છે કે તેઓ ફક્ત કંપનીને પાંચ-પોઇન્ટ માર્ગદર્શિકા આપે છે અને પછી છ મહિના પછી પાછા આવે છે અને જુઓ કે શું થયું. વેલ્યુ સ્ટ્રીમ મેપિંગ જેવી સારી સ્કીમમાં પણ, ચાલો કહીએ, બ્લાઈન્ડ સ્પોટ્સ છે. વિવિધ કંપનીઓના ડિરેક્ટરો સાથેની સેંકડો મુલાકાતો પછી, મેં એક ચોક્કસ પેટર્ન વિકસાવી છે જે અમને તેના ઘટકોમાં સમસ્યાને વિભાજીત કરવાની મંજૂરી આપે છે, અને હવે અમે આ દરેક ઘટકોની ક્રમમાં ચર્ચા કરીશું. કોઈપણ તકનીકી ઉકેલો લાગુ કરતાં પહેલાં, હું આ પેટર્નનો ઉપયોગ કરું છું, અને પરિણામે, મારી બધી દિવાલો આકૃતિઓથી ઢંકાયેલી છે. તાજેતરમાં હું એક મ્યુચ્યુઅલ ફંડ સાથે કામ કરી રહ્યો હતો અને મેં આવી 100-150 યોજનાઓ પૂરી કરી.

ખરાબ સંસ્કૃતિ નાસ્તા માટે સારા અભિગમો ખાય છે

મુખ્ય વિચાર આ છે: જો સંસ્થાની સંસ્કૃતિ પોતે જ ખરાબ હોય તો Lean, Agile, SAFE અને DevOpsની કોઈ રકમ મદદ કરશે નહીં. તે સ્કુબા ગિયર વિના ઊંડાણમાં ડાઇવિંગ કરવા અથવા એક્સ-રે વિના ચલાવવા જેવું છે. બીજા શબ્દોમાં કહીએ તો, ડ્રકર અને ડેમિંગને સમજાવવા માટે: એક ખરાબ સંગઠનાત્મક સંસ્કૃતિ કોઈપણ સારી સિસ્ટમને ગૂંગળાવ્યા વિના ગળી જશે.

આ મુખ્ય સમસ્યાને ઉકેલવા માટે, તમારે નીચેના પગલાં લેવાની જરૂર છે:

1. બધા કાર્યને દૃશ્યક્ષમ બનાવો: તમારે બધા કાર્યને દૃશ્યમાન બનાવવાની જરૂર છે. તે અર્થમાં નથી કે તે અમુક સ્ક્રીન પર પ્રદર્શિત હોવું આવશ્યક છે, પરંતુ તે અર્થમાં કે તે અવલોકનક્ષમ હોવું જોઈએ.
2. કોન્સોલિડેટેડ વર્ક મેનેજમેન્ટ સિસ્ટમ્સ: મેનેજમેન્ટ સિસ્ટમને એકીકૃત કરવાની જરૂર છે. "આદિવાસી" જ્ઞાન અને સંસ્થાકીય જ્ઞાનની સમસ્યામાં, 9માંથી 10 કેસોમાં અવરોધ લોકો છે. પુસ્તકમાં "ફોનિક્સ પ્રોજેક્ટ" સમસ્યા એક જ વ્યક્તિ, બ્રેન્ટ સાથે હતી, જેના કારણે પ્રોજેક્ટ ત્રણ વર્ષ પાછળ હતો. અને હું દરેક જગ્યાએ આ "બ્રેન્ટ્સ" માં દોડું છું. આ અવરોધોને ઉકેલવા માટે, હું અમારી સૂચિ પરની આગામી બે વસ્તુઓનો ઉપયોગ કરું છું.
3. અવરોધ પદ્ધતિનો સિદ્ધાંત: અવરોધોનો સિદ્ધાંત.
4. સહયોગ હેક્સ: સહયોગ હેક્સ.
5. ટોયોટા કાટા (કોચિંગ કાતા): હું ટોયોટા કાટા વિશે વધુ વાત કરીશ નહીં. જો રસ હોય તો, મારા ગીથબ પર પ્રસ્તુતિઓ છે આમાંના લગભગ દરેક વિષયો પર.
6. માર્કેટ ઓરિએન્ટેડ ઓર્ગેનાઈઝેશન: બજાર લક્ષી સંસ્થા.
7. શિફ્ટ-ડાબે ઓડિટર: ચક્રના પ્રારંભિક તબક્કામાં ઓડિટ.

હું એક સંસ્થા સાથે ખૂબ જ સરળ રીતે કામ કરવાનું શરૂ કરું છું: હું કંપનીમાં જાઉં છું અને કર્મચારીઓ સાથે વાત કરું છું. જેમ તમે જોઈ શકો છો, કોઈ ઉચ્ચ તકનીક નથી. તમારે ફક્ત કંઈક લખવાની જરૂર છે. હું એક રૂમમાં ઘણી ટીમોને ભેગી કરું છું અને મારા 7 આર્કીટાઇપ્સના પરિપ્રેક્ષ્યમાં તેઓ મને શું કહે છે તેનું વિશ્લેષણ કરું છું. અને પછી હું તેમને જાતે માર્કર આપું છું અને તેમને બોર્ડ પર તે બધું લખવાનું કહું છું જે તેઓએ અત્યાર સુધી મોટેથી કહ્યું છે. સામાન્ય રીતે આ પ્રકારની મીટિંગ્સમાં એક વ્યક્તિ હોય છે જે બધું લખે છે, અને શ્રેષ્ઠ રીતે તે 10% ચર્ચા લખી શકે છે. મારી પદ્ધતિથી, આ આંકડો લગભગ 40% સુધી વધારી શકાય છે.

(આ દ્રષ્ટાંત અલગથી જોઈ શકાય છે લિંક જુઓ)

મારો અભિગમ વિલિયમ સ્નેડરના કામ પર આધારિત છે. રિએન્જિનિયરિંગ વિકલ્પ). અભિગમ એ વિચાર પર આધારિત છે કે કોઈપણ સંસ્થાને ચાર ચોરસમાં વિભાજિત કરી શકાય છે. મારા માટે આ યોજના સામાન્ય રીતે તે સેંકડો અન્ય યોજનાઓ સાથે કામ કરવાનું પરિણામ છે જે સંસ્થાનું વિશ્લેષણ કરતી વખતે ઊભી થાય છે. ધારો કે અમારી પાસે ઉચ્ચ સ્તરના નિયંત્રણ સાથે સંસ્થા છે, પરંતુ ઓછી યોગ્યતા સાથે. આ એક અત્યંત અનિચ્છનીય વિકલ્પ છે: જ્યારે દરેક વ્યક્તિ લાઇન તરફ વળે છે, પરંતુ શું કરવું તે કોઈને ખબર નથી.

થોડો સારો વિકલ્પ એ છે કે જેમાં ઉચ્ચ સ્તરનું નિયંત્રણ અને યોગ્યતા હોય. જો આવી કંપની નફાકારક છે, તો કદાચ તેને DevOpsની જરૂર નથી. એવી કંપની સાથે કામ કરવું સૌથી રસપ્રદ છે કે જેમાં ઉચ્ચ સ્તરનું નિયંત્રણ, ઓછી યોગ્યતા અને સહકાર હોય, પરંતુ તે જ સમયે ઉચ્ચ સ્તરની સંસ્કૃતિ (ખેતી). આનો અર્થ એ છે કે કંપની પાસે ઘણા બધા લોકો છે જેઓ ત્યાં કામ કરવાનું પસંદ કરે છે અને લેબર ટર્નઓવર ઓછું છે.

(આ દ્રષ્ટાંત અલગથી જોઈ શકાય છે લિંક જુઓ)

મને એવું લાગે છે કે કઠોર માર્ગદર્શિકા સાથેની પદ્ધતિઓ સત્યને પ્રાપ્ત કરવાના માર્ગમાં અંત આવે છે. ખાસ કરીને વેલ્યુ સ્ટ્રીમ મેપિંગમાં, માહિતીની રચના કેવી રીતે કરવી તે અંગે ઘણા નિયમો છે. કામના પ્રારંભિક તબક્કામાં, જેની હું હમણાં વાત કરી રહ્યો છું, કોઈને આ નિયમોની જરૂર નથી. જો તેના હાથમાં માર્કર ધરાવતી વ્યક્તિ બોર્ડ પર કંપનીની વાસ્તવિક પરિસ્થિતિનું વર્ણન કરે છે, તો આ બાબતોની સ્થિતિને સમજવાનો શ્રેષ્ઠ માર્ગ છે. આવી માહિતી ડિરેક્ટરો સુધી પહોંચતી નથી. આ ક્ષણે, વ્યક્તિને વિક્ષેપિત કરવો અને કહેવું કે તેણે કોઈ પ્રકારનું તીર ખોટી રીતે દોર્યું તે મૂર્ખ છે. આ તબક્કે, સરળ નિયમોનો ઉપયોગ કરવો વધુ સારું છે, ઉદાહરણ તરીકે: બહુ-રંગીન માર્કર્સનો ઉપયોગ કરીને મલ્ટી-લેવલ એબ્સ્ટ્રેક્શન સરળ રીતે બનાવી શકાય છે.

હું પુનરાવર્તન કરું છું, ઉચ્ચ તકનીક નથી. બ્લેક માર્કર બધું કેવી રીતે કાર્ય કરે છે તેની ઉદ્દેશ્ય વાસ્તવિકતા દર્શાવે છે. લાલ માર્કર વડે, લોકો વર્તમાન સ્થિતિ વિશે તેમને શું ગમતું નથી તે ચિહ્નિત કરે છે. તે મહત્વનું છે કે તેઓ આ લખે, હું નહીં. જ્યારે હું મીટિંગ પછી CIO પાસે જાઉં છું, ત્યારે હું 10 વસ્તુઓની સૂચિ આપતો નથી જેને ઠીક કરવાની જરૂર છે. હું કંપનીના લોકો શું કહે છે અને હાલની સાબિત પેટર્ન વચ્ચે જોડાણ શોધવાનો પ્રયત્ન કરું છું. છેલ્લે, વાદળી માર્કર સમસ્યાના સંભવિત ઉકેલો સૂચવે છે.

(આ દ્રષ્ટાંત અલગથી જોઈ શકાય છે લિંક જુઓ)

આ અભિગમનું ઉદાહરણ હવે ઉપર દર્શાવવામાં આવ્યું છે. આ વર્ષની શરૂઆતમાં મેં એક બેંકમાં કામ કર્યું. ત્યાંના સિક્યોરિટી લોકોને ખાતરી હતી કે તેઓ ડિઝાઇન અને રિવ્યૂની જરૂરિયાત માટે ન આવે.

(આ દ્રષ્ટાંત અલગથી જોઈ શકાય છે લિંક જુઓ)

અને પછી અમે અન્ય વિભાગોના લોકો સાથે વાત કરી અને તે બહાર આવ્યું કે લગભગ 8 વર્ષ પહેલાં, સોફ્ટવેર ડેવલપર્સે સુરક્ષા કર્મચારીઓને નોકરીમાંથી કાઢી મૂક્યા કારણ કે તેઓ કામ ધીમું કરી રહ્યા હતા. અને પછી તે પ્રતિબંધમાં ફેરવાઈ ગયું, જેને ધ્યાનમાં લેવામાં આવ્યું હતું. જોકે વાસ્તવમાં કોઈ પ્રતિબંધ નહોતો.

અમારી મીટિંગ અત્યંત ગૂંચવણભરી રીતે આગળ વધી: લગભગ ત્રણ કલાક સુધી, પાંચ જુદી જુદી ટીમો મને સમજાવી શકી નહીં કે કોડ અને એસેમ્બલી વચ્ચે શું થઈ રહ્યું છે. અને આ સૌથી સરળ વસ્તુ લાગશે. મોટાભાગના DevOps સલાહકારો આગળ ધારે છે કે દરેકને આ પહેલેથી જ ખબર છે.

પછી આઈટી ગવર્નન્સનો હવાલો સંભાળનાર વ્યક્તિ, જે ચાર કલાક સુધી મૌન હતો, જ્યારે અમે તેમના વિષય પર પહોંચ્યા ત્યારે અચાનક જીવ આવ્યો, અને તેણે અમને ખૂબ લાંબા સમય સુધી રોક્યો. અંતે મેં તેને પૂછ્યું કે તે મીટિંગ વિશે શું વિચારે છે, અને હું તેનો જવાબ ક્યારેય ભૂલીશ નહીં. તેણે કહ્યું: "મને લાગતું હતું કે અમારી બેંક પાસે સૉફ્ટવેર પહોંચાડવાની માત્ર બે રીત છે, પરંતુ હવે હું જાણું છું કે તેમાંથી પાંચ છે, અને મને ત્રણ વિશે પણ ખબર નથી."

(આ દ્રષ્ટાંત અલગથી જોઈ શકાય છે લિંક જુઓ)

આ બેંકમાં છેલ્લી મીટિંગ ઈન્વેસ્ટમેન્ટ સોફ્ટવેર ટીમ સાથે થઈ હતી. તેણીની સાથે જ તે બહાર આવ્યું કે કાગળની શીટ પર માર્કર સાથે આકૃતિઓ લખવી એ બોર્ડ કરતાં વધુ સારી છે, અને સ્માર્ટબોર્ડ કરતાં પણ વધુ સારી છે.

તમે જે ફોટા જુઓ છો તે અમારી મીટિંગના ચોથા દિવસે હોટેલ કોન્ફરન્સ રૂમ કેવો દેખાતો હતો. અને અમે આ યોજનાઓનો ઉપયોગ પેટર્ન, એટલે કે, આર્કીટાઇપ્સ શોધવા માટે કર્યો.

તેથી, હું કામદારોને પ્રશ્નો પૂછું છું, તેઓ ત્રણ રંગો (કાળો, લાલ અને વાદળી) ના માર્કર સાથે જવાબો લખે છે. હું પુરાતત્ત્વો માટે તેમના જવાબોનું વિશ્લેષણ કરું છું. હવે ચાલો ક્રમમાં તમામ આર્કીટાઇપ્સની ચર્ચા કરીએ.

1. બધા કાર્યને દૃશ્યક્ષમ બનાવો: કાર્યને દૃશ્યમાન બનાવો

હું જેની સાથે કામ કરું છું તે મોટાભાગની કંપનીઓમાં અજાણ્યા કામની ટકાવારી ખૂબ ઊંચી છે. ઉદાહરણ તરીકે, આ ત્યારે થાય છે જ્યારે એક કર્મચારી બીજા પાસે આવે છે અને ખાલી કંઈક કરવાનું કહે છે. મોટી સંસ્થાઓમાં, 60% બિનઆયોજિત કાર્ય હોઈ શકે છે. અને 40% સુધીનું કામ કોઈપણ રીતે દસ્તાવેજીકૃત નથી. જો તે બોઇંગ હોત, તો હું મારા જીવનમાં ફરી ક્યારેય તેમના વિમાનમાં બેસી ન હોત. જો અડધા કામનું જ દસ્તાવેજીકરણ કરવામાં આવે તો ખબર પડતી નથી કે આ કામ યોગ્ય રીતે થઈ રહ્યું છે કે નહીં. અન્ય તમામ પદ્ધતિઓ નકામી હોવાનું બહાર આવ્યું છે - કોઈ પણ વસ્તુને સ્વચાલિત કરવાનો પ્રયાસ કરવાનો કોઈ અર્થ નથી, કારણ કે જાણીતું 50% એ કાર્યનો સૌથી સુસંગત અને સ્પષ્ટ ભાગ હોઈ શકે છે, જેનું સ્વચાલન શ્રેષ્ઠ પરિણામો આપશે નહીં, અને તમામ ખરાબ. વસ્તુઓ અદ્રશ્ય અડધા છે. દસ્તાવેજોની ગેરહાજરીમાં, તમામ પ્રકારના હેક્સ અને છુપાયેલા કાર્યને શોધવાનું અશક્ય છે, અવરોધો શોધવા માટે નહીં, તે ખૂબ જ "બ્રેન્ટ્સ" કે જેના વિશે મેં પહેલેથી જ વાત કરી છે. ડોમિનિકા ડીગ્રાન્ડિસનું એક અદ્ભુત પુસ્તક છે "કાર્યને દૃશ્યક્ષમ બનાવવું". તેણી છતી કરે છે પાંચ અલગ અલગ "ટાઇમ લીક્સ" (સમયના ચોર):

• પ્રક્રિયામાં ખૂબ કામ (WIP)
• અજ્ઞાત અવલંબન
• બિનઆયોજિત કાર્ય
• વિરોધાભાસી પ્રાથમિકતાઓ
• ઉપેક્ષિત કામ

આ ખૂબ જ મૂલ્યવાન વિશ્લેષણ છે અને પુસ્તક મહાન છે, પરંતુ આ બધી સલાહ નકામી છે જો માત્ર 50% ડેટા જ દેખાય. ડોમિનિકા દ્વારા પ્રસ્તાવિત પદ્ધતિઓનો ઉપયોગ કરી શકાય છે જો 90% થી વધુની ચોકસાઈ પ્રાપ્ત થાય. હું એવી પરિસ્થિતિઓ વિશે વાત કરું છું જ્યાં બોસ ગૌણને 15-મિનિટનું કાર્ય આપે છે, પરંતુ તે તેને ત્રણ દિવસ લે છે; પરંતુ બોસ ખરેખર જાણતા નથી કે આ ગૌણ અન્ય ચાર કે પાંચ લોકો પર નિર્ભર છે.

ફોનિક્સ પ્રોજેક્ટ એ પ્રોજેક્ટ વિશેની અદ્ભુત વાર્તા છે જે ત્રણ વર્ષ ખૂબ મોડું હતું. એક પાત્રને આ કારણે બરતરફીનો સામનો કરવો પડે છે, અને તે બીજા પાત્ર સાથે મળે છે જેને એક પ્રકારના સોક્રેટીસ તરીકે રજૂ કરવામાં આવે છે. તે ખરેખર શું ખોટું થયું તે સમજવામાં મદદ કરે છે. તે તારણ આપે છે કે કંપનીમાં એક સિસ્ટમ એડમિનિસ્ટ્રેટર છે, જેનું નામ બ્રેન્ટ છે, અને તમામ કામ કોઈક રીતે તેના દ્વારા થાય છે. એક મીટિંગમાં, ગૌણમાંના એકને પૂછવામાં આવે છે: દરેક અડધા કલાકના કાર્યમાં એક અઠવાડિયા કેમ લાગે છે? જવાબ એ ક્યુઇંગ થિયરી અને લિટલના કાયદાની ખૂબ જ સરળ રજૂઆત છે, અને આ પ્રસ્તુતિમાં તે તારણ આપે છે કે 90% ઓક્યુપન્સી પર, કામના દરેક કલાકમાં 9 કલાકનો સમય લાગે છે. દરેક કાર્ય સાત અન્ય લોકોને મોકલવાની જરૂર છે, જેથી તે કલાક 63 કલાક, 7 ગુણ્યા 9 બને. હું શું કહું છું કે લિટલના કાયદા અથવા કોઈપણ જટિલ કતાર સિદ્ધાંતનો ઉપયોગ કરવા માટે, તમારી પાસે ઓછામાં ઓછો ડેટા હોવો જરૂરી છે.

તેથી જ્યારે હું દૃશ્યતા વિશે વાત કરું છું, ત્યારે મારો અર્થ એ નથી કે બધું સ્ક્રીન પર છે, પરંતુ તમારી પાસે ઓછામાં ઓછો ડેટા છે. જ્યારે તેઓ કરે છે, ત્યારે તે ઘણીવાર બહાર આવે છે કે ત્યાં ખૂબ મોટી માત્રામાં બિનઆયોજિત કાર્ય છે જે કોઈક રીતે બ્રેન્ટને મોકલવામાં આવે છે જ્યારે તેની કોઈ જરૂર નથી. અને બ્રેન્ટ એક મહાન વ્યક્તિ છે, તે ક્યારેય ના કહેશે નહીં, પરંતુ તે કોઈને કહેતો નથી કે તે તેનું કામ કેવી રીતે કરે છે.

જ્યારે કાર્ય દૃશ્યમાન થાય છે, ત્યારે ડેટાને સરસ રીતે વર્ગીકૃત કરી શકાય છે (ફોટોમાં ડોમિનિકા જે કરી રહી છે તે જ છે), પાંચ વખતના લીક્સનું એબ્સ્ટ્રેક્શન લાગુ કરી શકાય છે, અને ઓટોમેશન લાગુ કરી શકાય છે.

2. વર્ક મેનેજમેન્ટ સિસ્ટમ્સને એકીકૃત કરો: ટાસ્ક મેનેજમેન્ટ

હું જે આર્કીટાઇપ્સ વિશે વાત કરી રહ્યો છું તે એક પ્રકારનો પિરામિડ છે. જો પ્રથમ યોગ્ય રીતે કરવામાં આવે છે, તો પછી બીજું પહેલેથી જ એક પ્રકારનું એડ-ઓન છે. આમાંના ઘણા સ્ટાર્ટઅપ્સ માટે કામ કરતા નથી, ફોર્ચ્યુન 5000 જેવી મોટી કંપનીઓ માટે તેમને ધ્યાનમાં રાખવાની જરૂર છે. છેલ્લી જે કંપનીમાં મેં કામ કર્યું તેમાં 10 ટિકિટિંગ સિસ્ટમ્સ હતી. એક ટીમ પાસે Remedy હતી, બીજી ટીમે તેની પોતાની સિસ્ટમ લખી હતી, ત્રીજી ટીમે જીરાનો ઉપયોગ કર્યો હતો અને કેટલાકે ઈમેઈલ સાથે કર્યું હતું. જો કંપની પાસે 30 અલગ-અલગ પાઈપલાઈન હોય તો આ જ સમસ્યા ઊભી થાય છે, પરંતુ મારી પાસે આવા તમામ કેસોની ચર્ચા કરવાનો સમય નથી.

હું લોકો સાથે બરાબર ચર્ચા કરું છું કે ટિકિટ કેવી રીતે બનાવવામાં આવે છે, તેમનું આગળ શું થાય છે અને તેમને કેવી રીતે અટકાવવામાં આવે છે. સૌથી રસપ્રદ વાત એ છે કે અમારી સભાઓમાં લોકો એકદમ નિષ્ઠાપૂર્વક બોલે છે. મેં પૂછ્યું કે કેટલા લોકો ટિકિટો પર "નાની / કોઈ અસર નથી" મૂકે છે જેને ખરેખર "મુખ્ય અસર" આપવી જોઈએ. તે બહાર આવ્યું છે કે લગભગ દરેક જણ આ કરે છે. હું નિંદામાં જોડાતો નથી અને લોકોને ઓળખવા માટે દરેક શક્ય રીતે પ્રયાસ કરતો નથી. જ્યારે તેઓ નિષ્ઠાપૂર્વક મારી પાસે કંઈક કબૂલ કરે છે, ત્યારે હું તે વ્યક્તિને આપતો નથી. પરંતુ જ્યારે લગભગ દરેક જણ સિસ્ટમને બાયપાસ કરે છે, ત્યારે તેનો અર્થ એ છે કે તમામ સુરક્ષા આવશ્યકપણે વિન્ડો ડ્રેસિંગ છે. તેથી, આ સિસ્ટમના ડેટામાંથી કોઈ નિષ્કર્ષ કાઢી શકાય નહીં.

ટિકિટ સમસ્યા હલ કરવા માટે, તમારે એક મુખ્ય સિસ્ટમ પસંદ કરવાની જરૂર છે. જો તમે જીરાનો ઉપયોગ કરો છો, તો તેને જીરા રાખો. જો કોઈ વિકલ્પ હોય, તો તે એકમાત્ર રહેવા દો. મુખ્ય વાત એ છે કે ટિકિટને વિકાસ પ્રક્રિયાના બીજા પગલા તરીકે જોવી જોઈએ. દરેક ક્રિયામાં ટિકિટ હોવી આવશ્યક છે, જે વિકાસના કાર્યપ્રવાહમાંથી પસાર થવી જોઈએ. ટીમને ટિકિટ મોકલવામાં આવે છે, જે તેમને સ્ટોરીબોર્ડ પર પોસ્ટ કરે છે અને પછી તેમની જવાબદારી લે છે.

આ ઈન્ફ્રાસ્ટ્રક્ચર અને કામગીરી સહિત તમામ વિભાગોને લાગુ પડે છે. આ કિસ્સામાં, બાબતોની સ્થિતિ વિશે ઓછામાં ઓછા કેટલાક બુદ્ધિગમ્ય વિચારની રચના કરવી શક્ય છે. એકવાર આ પ્રક્રિયા સ્થાપિત થઈ ગયા પછી, દરેક એપ્લિકેશન માટે કોણ જવાબદાર છે તે ઓળખવું અચાનક સરળ બની જાય છે. કારણ કે હવે અમે 50% નહીં, પરંતુ 98% નવી સેવાઓ પ્રાપ્ત કરીએ છીએ. જો આ મુખ્ય પ્રક્રિયા કામ કરે છે, તો પછી સમગ્ર સિસ્ટમમાં ચોકસાઈ સુધરે છે.

સેવાઓ પાઇપલાઇન

આ ફરીથી માત્ર મોટા કોર્પોરેશનોને લાગુ પડે છે. જો તમે નવા ક્ષેત્રમાં નવી કંપની છો, તો તમારી સ્લીવ્ઝ રોલ અપ કરો અને તમારા Travis CI અથવા CircleCI સાથે કામ કરો. જ્યારે ફોર્ચ્યુન 5000 કંપનીઓની વાત આવે છે, ત્યારે એક કેસ જે બેંકમાં બન્યો હતો જ્યાં હું કામ કરતો હતો. ગૂગલ તેમની પાસે આવ્યું અને તેમને જૂની IBM સિસ્ટમના ડાયાગ્રામ બતાવવામાં આવ્યા. ગૂગલના લોકોએ મૂંઝવણમાં પૂછ્યું - આનો સોર્સ કોડ ક્યાં છે? પરંતુ ત્યાં કોઈ સ્રોત કોડ નથી, GUI પણ નથી. આ વાસ્તવિકતા છે જેનો સામનો મોટી સંસ્થાઓએ કરવો પડે છે: પ્રાચીન મેઇનફ્રેમ પર 40 વર્ષ જૂના બેંક રેકોર્ડ્સ. મારો એક ક્લાયન્ટ સર્કિટ બ્રેકર પેટર્ન સાથે કુબરનેટ્સ કન્ટેનરનો ઉપયોગ કરે છે, ઉપરાંત કેઓસ મંકી, આ બધું કીબેંક એપ્લિકેશન માટે. પરંતુ આ કન્ટેનર આખરે COBOL એપ્લિકેશન સાથે જોડાય છે.

Google ના છોકરાઓને સંપૂર્ણ વિશ્વાસ હતો કે તેઓ મારા ક્લાયંટની બધી સમસ્યાઓ હલ કરશે, અને પછી તેઓએ પ્રશ્નો પૂછવાનું શરૂ કર્યું: IBM ડેટાપાઇપ શું છે? તેમને કહેવામાં આવે છે: આ એક કનેક્ટર છે. તે શું જોડે છે? Sperry સિસ્ટમ માટે. અને તે શું છે? અને તેથી વધુ. પ્રથમ નજરમાં એવું લાગે છે: ત્યાં કયા પ્રકારનાં DevOps હોઈ શકે છે? પરંતુ હકીકતમાં, તે શક્ય છે. ત્યાં ડિલિવરી સિસ્ટમ્સ છે જે તમને ડિલિવરી ટીમોને વર્કફ્લો સોંપવાની મંજૂરી આપે છે.

3. અવરોધોનો સિદ્ધાંત: અવરોધોનો સિદ્ધાંત

ચાલો ત્રીજા આર્કીટાઇપ તરફ આગળ વધીએ: સંસ્થાકીય/"આદિવાસી" જ્ઞાન. એક નિયમ તરીકે, કોઈપણ સંસ્થામાં એવા ઘણા લોકો હોય છે જેઓ બધું જાણે છે અને બધું મેનેજ કરે છે. આ તે લોકો છે જેઓ સંગઠનમાં સૌથી લાંબો સમય રહ્યા છે અને જેઓ તમામ ઉકેલો જાણે છે.

જ્યારે આ ડાયાગ્રામ પર આવે છે, ત્યારે હું ખાસ કરીને આવા લોકોને માર્કર વડે વર્તુળ કરું છું: ઉદાહરણ તરીકે, તે તારણ આપે છે કે બધી મીટિંગ્સમાં ચોક્કસ લૌ હાજર હોય છે. અને તે મારા માટે સ્પષ્ટ છે: આ સ્થાનિક બ્રેન્ટ છે. જ્યારે CIO મારી વચ્ચે ટી-શર્ટ અને સ્નીકર્સ અને સૂટમાં IBM ના વ્યક્તિની પસંદગી કરે છે, ત્યારે મને પસંદ કરવામાં આવે છે કારણ કે હું ડિરેક્ટરને એવી વસ્તુઓ કહી શકું છું જે અન્ય વ્યક્તિ કહેશે નહીં અને ડિરેક્ટરને સાંભળવું ગમશે નહીં. . હું તેમને કહું છું કે તેમની કંપનીમાં અડચણ ફ્રેડ નામની વ્યક્તિ છે અને લૌ નામની કોઈ વ્યક્તિ છે. આ અડચણને દૂર કરવાની જરૂર છે, તેમનું જ્ઞાન તેમની પાસેથી એક યા બીજી રીતે મેળવવાની જરૂર છે.

આ પ્રકારની સમસ્યાને ઉકેલવા માટે, હું, ઉદાહરણ તરીકે, Slack નો ઉપયોગ કરવાનું સૂચન કરી શકું છું. એક સ્માર્ટ ડિરેક્ટર પૂછશે - કેમ? સામાન્ય રીતે, આવા કિસ્સાઓમાં, DevOps સલાહકારો જવાબ આપે છે: કારણ કે દરેક જણ તે કરે છે. જો દિગ્દર્શક ખરેખર સ્માર્ટ હોય, તો તે કહેશે: તો શું. અને આ તે છે જ્યાં સંવાદ સમાપ્ત થાય છે. અને આનો મારો જવાબ છે: કારણ કે કંપનીમાં ચાર અવરોધો છે, ફ્રેડ, લૌ, સુસી અને જેન. તેમના જ્ઞાનને સંસ્થાકીય બનાવવા માટે, સૌ પ્રથમ સ્લેકનો પરિચય કરાવવો જોઈએ. તમારી બધી વિકિ સંપૂર્ણ નોનસેન્સ છે કારણ કે તેમના અસ્તિત્વ વિશે કોઈ જાણતું નથી. જો એન્જિનિયરિંગ ટીમ ફ્રન્ટ-એન્ડ અને બેક-એન્ડ ડેવલપમેન્ટમાં સામેલ હોય અને દરેકને એ જાણવાની જરૂર હોય કે તેઓ ફ્રન્ટ-એન્ડ ડેવલપમેન્ટ ટીમ અથવા ઈન્ફ્રાસ્ટ્રક્ચર ટીમનો પ્રશ્નો સાથે સંપર્ક કરી શકે છે. ત્યારે જ લૌ અથવા ફ્રેડ પાસે વિકિમાં જોડાવાનો સમય હશે. અને પછી સ્લેકમાં કોઈ પૂછશે કે શા માટે, કહો, પગલું 5 કામ કરતું નથી. અને પછી લૌ અથવા ફ્રેડ વિકિ પરની સૂચનાઓને સુધારશે. જો તમે આ પ્રક્રિયા સ્થાપિત કરો છો, તો ઘણી બધી વસ્તુઓ તેમના પોતાના પર આવી જશે.

આ મારો મુખ્ય મુદ્દો છે: કોઈપણ ઉચ્ચ તકનીકોની ભલામણ કરવા માટે, તમારે પહેલા તેના માટે પાયો ક્રમમાં મૂકવો જોઈએ, અને આ હમણાં જ વર્ણવેલ લો-ટેક સોલ્યુશન્સ સાથે કરી શકાય છે. જો તમે ઉચ્ચ તકનીકીઓથી પ્રારંભ કરો છો અને તે શા માટે જરૂરી છે તે સમજાવતા નથી, તો પછી, એક નિયમ તરીકે, આ સારી રીતે સમાપ્ત થતું નથી. અમારા ગ્રાહકોમાંથી એક Azure ML નો ઉપયોગ કરે છે, જે ખૂબ જ સસ્તો અને સરળ ઉકેલ છે. તેમના લગભગ 30% પ્રશ્નોના જવાબ સ્વ-શિક્ષણ મશીન દ્વારા જ આપવામાં આવ્યા હતા. અને આ વસ્તુ ઓપરેટરો દ્વારા લખવામાં આવી હતી જેઓ ડેટા વિજ્ઞાન, આંકડાશાસ્ત્ર અથવા ગણિતમાં સામેલ ન હતા. આ નોંધપાત્ર છે. આવા ઉકેલની કિંમત ન્યૂનતમ છે.

4. સહયોગ હેક્સ: સહયોગ હેક્સ

ચોથો આર્કિટાઇપ એ એકલતાનો સામનો કરવાની જરૂરિયાત છે. મોટાભાગના લોકો આ પહેલાથી જ જાણે છે: અલગતા દુશ્મનાવટ પેદા કરે છે. જો દરેક વિભાગ તેના પોતાના ફ્લોર પર હોય, અને લોકો લિફ્ટ સિવાય કોઈપણ રીતે એકબીજા સાથે છેદે નહીં, તો તેમની વચ્ચે દુશ્મનાવટ ખૂબ જ સરળતાથી ઊભી થાય છે. પરંતુ જો, તેનાથી વિપરીત, લોકો એકબીજા સાથે એક જ રૂમમાં હોય, તો તે તરત જ નીકળી જાય છે. જ્યારે કોઈ વ્યક્તિ કેટલાક સામાન્ય આરોપોને ફેંકી દે છે, ઉદાહરણ તરીકે, આવા અને આવા ઇન્ટરફેસ ક્યારેય કામ કરે છે, ત્યારે આવા આરોપને ડિકન્સ્ટ્રક્ટ કરવાનું કંઈ સરળ નથી. ઈન્ટરફેસ લખનારા પ્રોગ્રામરોએ માત્ર ચોક્કસ પ્રશ્નો પૂછવાનું શરૂ કરવાની જરૂર છે, અને તે ટૂંક સમયમાં સ્પષ્ટ થઈ જશે કે, ઉદાહરણ તરીકે, વપરાશકર્તા ફક્ત ટૂલનો ખોટી રીતે ઉપયોગ કરી રહ્યો હતો.

એકલતાને દૂર કરવાની ઘણી રીતો છે. મને એકવાર ઑસ્ટ્રેલિયામાં બેંક માટે સલાહ લેવા માટે કહેવામાં આવ્યું હતું, પરંતુ મેં તે કરવાનો ઇનકાર કર્યો હતો કારણ કે મારા બે બાળકો અને એક પત્ની છે. હું તેમને મદદ કરવા માટે માત્ર ગ્રાફિકલ વાર્તા કહેવાની ભલામણ કરી શકતો હતો. આ એવી વસ્તુ છે જે કામ કરવા માટે સાબિત થાય છે. બીજી રસપ્રદ રીત દુર્બળ કોફી મીટિંગ્સ છે. મોટી સંસ્થામાં, જ્ઞાનના પ્રસાર માટે આ એક ઉત્તમ વિકલ્પ છે. વધુમાં, તમે આંતરિક ડેવોપ્સ ડે, હેકાથોન વગેરેનું આયોજન કરી શકો છો.

5. કોચિંગ કાતા

જેમ મેં શરૂઆતમાં ચેતવણી આપી હતી, હું આજે આ વિશે વાત કરીશ નહીં. જો તમને રસ હોય, તો તમે એક નજર કરી શકો છો મારી કેટલીક પ્રસ્તુતિઓ.

માઇક રોધર તરફથી આ વિષય પર સારી વાત પણ છે:

6. બજાર લક્ષી: બજાર લક્ષી સંસ્થા

અહીં વિવિધ સમસ્યાઓ છે. ઉદાહરણ તરીકે, "I" લોકો, "T" લોકો અને "E" લોકો. "હું" લોકો એ છે જે ફક્ત એક જ કામ કરે છે. સામાન્ય રીતે તેઓ અલગ વિભાગો ધરાવતી સંસ્થાઓમાં અસ્તિત્વ ધરાવે છે. "T" એ છે જ્યારે વ્યક્તિ એક વસ્તુમાં સારી હોય છે પણ અન્ય કેટલીક બાબતોમાં પણ સારી હોય છે. "ઇ" અથવા તો "કાંસકો" એ છે જ્યારે વ્યક્તિ પાસે ઘણી કુશળતા હોય છે.

કોનવેનો કાયદો અહીં કામ કરે છે (કોનવેનો કાયદો), જે સૌથી સરળ સ્વરૂપમાં નીચે પ્રમાણે કહી શકાય: જો ત્રણ ટીમો કમ્પાઇલર પર કામ કરે છે, તો પરિણામ ત્રણ ભાગોનું કમ્પાઇલર હશે. તેથી, જો કોઈ સંસ્થામાં ઉચ્ચ સ્તરનું અલગતા હોય, તો આ સંસ્થામાં કુબરનેટ્સ, સર્કિટ બ્રેકર, API એક્સ્ટેન્સિબિલિટી અને અન્ય ફેન્સી વસ્તુઓ પણ સંસ્થાની જેમ જ ગોઠવવામાં આવશે. કોનવે અનુસાર સખત રીતે અને તમારા બધા યુવાન ગીક્સને વખોડવા માટે.

આ સમસ્યાનો ઉકેલ ઘણી વખત વર્ણવવામાં આવ્યો છે. ઉદાહરણ તરીકે, ફર્નાન્ડો ફર્નાન્ડીઝ દ્વારા વર્ણવેલ સંસ્થાકીય આર્કીટાઇપ્સ છે. તે સમસ્યારૂપ આર્કિટેક્ચર કે જેના વિશે મેં હમણાં જ વાત કરી છે, એકલતા સાથે, એક કાર્યલક્ષી આર્કિટેક્ચર છે. બીજો પ્રકાર સૌથી ખરાબ છે, મેટ્રિક્સ આર્કિટેક્ચર, અન્ય બેની વાસણ. ત્રીજું તે છે જે મોટાભાગના સ્ટાર્ટઅપ્સમાં જોવા મળે છે, અને મોટી કંપનીઓ પણ આ પ્રકારને મેચ કરવાનો પ્રયાસ કરી રહી છે. તે બજાર લક્ષી સંસ્થા છે. અહીં અમે ગ્રાહકની વિનંતીઓનો સૌથી ઝડપી પ્રતિસાદ પ્રાપ્ત કરવા માટે ઑપ્ટિમાઇઝ કરીએ છીએ. આને કેટલીકવાર ફ્લેટ સંસ્થા કહેવામાં આવે છે.

ઘણા લોકો આ રચનાને જુદી જુદી રીતે વર્ણવે છે, મને શબ્દો ગમે છે ટીમો બનાવો / ચલાવો, એમેઝોન પર તેઓ તેને કહે છે બે પિઝા ટીમ. આ માળખામાં, તમામ પ્રકારના "I" લોકોને એક સેવાની આસપાસ જૂથબદ્ધ કરવામાં આવે છે, અને ધીમે ધીમે તેઓ "T" ટાઇપની નજીક જાય છે, અને જો યોગ્ય વ્યવસ્થાપન સ્થાને હોય, તો તેઓ "E" પણ બની શકે છે. અહીં પ્રથમ પ્રતિવાદ એ છે કે આવી રચનામાં બિનજરૂરી તત્વો હોય છે. જો તમારી પાસે પરીક્ષકોનો વિશેષ વિભાગ હોય તો તમારે દરેક વિભાગમાં પરીક્ષકની શા માટે જરૂર છે? જેનો હું જવાબ આપું છું: આ કિસ્સામાં વધારાના ખર્ચ એ સમગ્ર સંસ્થા માટે ભવિષ્યમાં "E" પ્રકાર બનવાની કિંમત છે. આ સ્ટ્રક્ચરમાં, ટેસ્ટર ધીમે ધીમે નેટવર્ક્સ, આર્કિટેક્ચર, ડિઝાઇન વગેરે વિશે શીખે છે. પરિણામે, સંસ્થામાં દરેક સહભાગી સંસ્થામાં બનેલી દરેક વસ્તુથી સંપૂર્ણપણે વાકેફ હોય છે. જો તમે જાણવા માંગતા હોવ કે આ યોજના ઉદ્યોગમાં કેવી રીતે કામ કરે છે, તો વાંચો માઇક રોધર, ટોયોટા કાટા.

7. શિફ્ટ-ડાબે ઑડિટર: ચક્રની શરૂઆતમાં ઑડિટ કરો. પ્રદર્શન પર સલામતી નિયમોનું પાલન

આ ત્યારે થાય છે જ્યારે તમારી ક્રિયાઓ ગંધની કસોટીમાં પાસ થતી નથી, તેથી વાત કરવા માટે. તમારા માટે કામ કરનારા લોકો મૂર્ખ નથી. જો, ઉપરના ઉદાહરણની જેમ, તેઓ દરેક જગ્યાએ નજીવી/કોઈ અસર નહીં કરે, તો આ ત્રણ વર્ષ ચાલ્યું, અને કોઈએ કંઈ જોયું નહીં, તો દરેક વ્યક્તિ સારી રીતે જાણે છે કે સિસ્ટમ કામ કરતી નથી. અથવા બીજું ઉદાહરણ - ફેરફાર સલાહકાર બોર્ડ, જ્યાં દર બુધવારે રિપોર્ટ સબમિટ કરવાની જરૂર છે. ત્યાં કામ કરતા લોકોનું એક જૂથ છે (બહુ સારી રીતે વેતન મળતું નથી), જેમને સૈદ્ધાંતિક રીતે, સમગ્ર સિસ્ટમ કેવી રીતે કાર્ય કરે છે તે જાણવું જોઈએ. અને છેલ્લાં પાંચ વર્ષોમાં, તમે કદાચ નોંધ્યું હશે કે અમારી સિસ્ટમો અતિ જટિલ છે. અને પાંચ કે છ લોકોએ એવા બદલાવ અંગે નિર્ણય લેવાનો હોય છે જે તેમણે નથી કર્યો અને જેના વિશે તેઓ કશું જાણતા નથી.

અલબત્ત, આ અભિગમ કામ કરતું નથી. મારે આવી વસ્તુઓથી છૂટકારો મેળવવો પડશે કારણ કે આ લોકો સિસ્ટમનું રક્ષણ કરતા નથી. નિર્ણય ટીમે જ લેવો જોઈએ, કારણ કે ટીમ તેના માટે જવાબદાર હોવી જોઈએ. નહિંતર, એક વિરોધાભાસી પરિસ્થિતિ ઊભી થાય છે જ્યારે મેનેજર કે જેમણે તેના જીવનમાં ક્યારેય કોડ લખ્યો નથી તે પ્રોગ્રામરને કોડ લખવામાં કેટલો સમય લેવો જોઈએ તે કહે છે. એક કંપની જેની સાથે મેં કામ કર્યું તેમાં 7 અલગ-અલગ બોર્ડ હતા જે દરેક ફેરફારની સમીક્ષા કરે છે, જેમાં આર્કિટેક્ચર બોર્ડ, પ્રોડક્ટ બોર્ડ વગેરેનો સમાવેશ થાય છે. ફરજિયાત રાહ જોવાનો સમયગાળો પણ હતો, જો કે એક કર્મચારીએ મને કહ્યું કે દસ વર્ષના કામમાં, આ ફરજિયાત સમયગાળા દરમિયાન આ વ્યક્તિ દ્વારા કરવામાં આવેલ ફેરફારને ક્યારેય કોઈએ નકારી કાઢ્યો નથી.

ઓડિટર્સને અમારી સાથે જોડાવા માટે આમંત્રિત કરવાની જરૂર છે, અને તેમને છૂટકારો મેળવવાની જરૂર નથી. તેમને કહો કે તમે અપરિવર્તનશીલ દ્વિસંગી કન્ટેનર લખો કે, જો તેઓ તમામ પરીક્ષણો પાસ કરે, તો કાયમ માટે અપરિવર્તનશીલ રહે છે. તેમને કહો કે તમારી પાસે કોડ તરીકે પાઇપલાઇન છે અને તેનો અર્થ શું છે તે સમજાવો. તેમને નીચેની સ્કીમ બતાવો: કન્ટેનરમાં અપરિવર્તનશીલ વાંચન-માત્ર દ્વિસંગી જે તમામ નબળાઈ પરીક્ષણો પાસ કરે છે; અને પછી માત્ર કોઈ તેને સ્પર્શતું નથી, તેઓ પાઇપલાઇન બનાવતી સિસ્ટમને પણ સ્પર્શતા નથી, કારણ કે તે ગતિશીલ રીતે પણ બનાવવામાં આવે છે. મારી પાસે ક્લાયન્ટ્સ છે, કેપિટલ વન, જે બ્લોકચેન જેવું કંઈક બનાવવા માટે વૉલ્ટનો ઉપયોગ કરી રહ્યાં છે. ઑડિટરને રસોઇયા પાસેથી "રેસિપિ" બતાવવાની જરૂર નથી; તે બ્લોકચેન બતાવવા માટે પૂરતું છે, જેમાંથી તે સ્પષ્ટ થાય છે કે ઉત્પાદનમાં જીરા ટિકિટનું શું થયું અને તેના માટે કોણ જવાબદાર છે.

અનુસાર અહેવાલ, Sonatype દ્વારા 2018 માં બનાવવામાં આવ્યું હતું, 2017 માં 87 બિલિયન OSS ડાઉનલોડ વિનંતીઓ હતી.

નબળાઈઓને કારણે થતા નુકસાન નિષેધાત્મક છે. તદુપરાંત, તમે જે આંકડાઓ હવે ઉપર જુઓ છો તેમાં તક ખર્ચનો સમાવેશ થતો નથી. ટૂંકમાં DevSecOps શું છે? હું તરત જ કહી દઉં કે આ નામ કેટલું સફળ છે તેની વાત કરવામાં મને રસ નથી. મુદ્દો એ છે કે દેવઓપ્સ ખૂબ સફળ થયા હોવાથી, આપણે તે પાઇપલાઇનમાં સુરક્ષા ઉમેરવાનો પ્રયાસ કરવો જોઈએ.

આ ક્રમનું ઉદાહરણ:


આ ચોક્કસ ઉત્પાદનો માટે ભલામણ નથી, જોકે મને તે બધા ગમે છે. મેં તેમને એક ઉદાહરણ તરીકે ટાંક્યા તે બતાવવા માટે કે DevOps, જે શરૂઆતમાં ઉદ્યોગમાં સંસ્થાકીય દાખલા પર આધારિત હતી, તે તમને ઉત્પાદન પર કામના દરેક તબક્કાને સ્વચાલિત કરવાની મંજૂરી આપે છે.

અને ત્યાં કોઈ કારણ નથી કે અમે સુરક્ષા માટે સમાન અભિગમ અપનાવી શક્યા નથી.

પરિણામ

નિષ્કર્ષ તરીકે, હું DevSecOps માટે કેટલીક ટીપ્સ આપીશ. તમારે તમારી સિસ્ટમ્સ બનાવવાની પ્રક્રિયામાં ઓડિટર્સનો સમાવેશ કરવાની જરૂર છે અને તેમને શિક્ષિત કરવામાં સમય પસાર કરવો પડશે. તમારે ઓડિટર્સ સાથે સહયોગ કરવાની જરૂર છે. આગળ, તમારે ખોટા હકારાત્મક સામે એકદમ નિર્દય લડાઈ લડવાની જરૂર છે. સૌથી મોંઘા નબળાઈ સ્કેનિંગ ટૂલ સાથે પણ, જો તમે જાણતા ન હોવ કે તમારો સિગ્નલ-ટુ-નોઈઝ રેશિયો શું છે, તો તમે તમારા વિકાસકર્તાઓમાં અત્યંત ખરાબ ટેવો પેદા કરી શકો છો. વિકાસકર્તાઓ ઇવેન્ટ્સથી અભિભૂત થઈ જશે અને તેમને ખાલી કાઢી નાખશે. જો તમે Equifax વાર્તા વિશે સાંભળ્યું હોય, તો તે જ ત્યાં થયું હતું, જ્યાં ઉચ્ચતમ ચેતવણી સ્તરને અવગણવામાં આવ્યું હતું. વધુમાં, નબળાઈઓને એવી રીતે સમજાવવાની જરૂર છે કે જે સ્પષ્ટ કરે કે તેઓ વ્યવસાયને કેવી રીતે અસર કરે છે. ઉદાહરણ તરીકે, તમે કહી શકો છો કે આ એકીફેક્સ વાર્તાની જેમ જ નબળાઈ છે. સુરક્ષા નબળાઈઓને અન્ય સૉફ્ટવેર સમસ્યાઓની જેમ જ ગણવામાં આવવી જોઈએ, એટલે કે, તેઓ એકંદર DevOps પ્રક્રિયામાં શામેલ હોવા જોઈએ. તમારે તેમની સાથે જીરા, કાનબન વગેરે દ્વારા કામ કરવાની જરૂર છે. વિકાસકર્તાઓએ એવું ન વિચારવું જોઈએ કે બીજું કોઈ આ કરશે - તેનાથી વિપરીત, દરેકને આ કરવું જોઈએ. છેવટે, તમારે લોકોને તાલીમ આપવા માટે ઊર્જા ખર્ચવાની જરૂર છે.

ઉપયોગી લિંક્સ

અહીં DevOops કોન્ફરન્સની કેટલીક વાતો છે જે તમને ઉપયોગી લાગી શકે છે:

• સેર્ગેઈ બર્ડનીકોવ, આર્ટીઓમ કાલિચકીન - સફળતાની વાર્તા, અથવા "દેવ+દેવઓપ્સ+ઓપ્સ" (видео, અહેવાલની ટ્રાન્સક્રિપ્ટ)
• બરુચ સદોગુર્સ્કી, લિયોનીડ ઇગોલનિક - સ્કેલ પર ડેવઓપ્સ: ત્રણ કૃત્યોમાં ગ્રીક ટ્રેજેડી (видео, અહેવાલની ટ્રાન્સક્રિપ્ટ)
• એલેક્ઝાંડર ટીટોવ, કિરીલ ટોલ્કાચેવ - DevOps, ઇજનેરો અને સમુદાય
• ટીમોથી લિસ્ટર - પાત્રો, સમુદાય અને સંસ્કૃતિ: સમૃદ્ધિ માટે મહત્વપૂર્ણ પરિબળો

તપાસ કાર્યક્રમ DevOops 2020 મોસ્કો - ત્યાં ઘણી બધી રસપ્રદ વસ્તુઓ પણ છે.

સોર્સ: www.habr.com