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

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

લિયોન રશિયનમાં ખૂબ જ રંગીન બોલે છે, તેથી જો તમારી પાસે 35-40 મિનિટ હોય, તો હું વિડિઓ જોવાની ભલામણ કરું છું. નીચે સમય બચાવવા માટે ટેક્સ્ટ સંસ્કરણ.

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

એક મહિના પહેલા

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

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

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

થોડું આગળ જોતાં, હું નોંધ કરીશ કે મેં મારું કામ સૌથી વધુ વાર્ષિક ટ્રાફિકના સમયગાળા દરમિયાન શરૂ કર્યું હતું, જે વિવિધ કારણોસર રસપ્રદ છે.

પ્લેટફોર્મ, જે માત્ર 2 વર્ષ જૂનું લાગતું હતું, તેમાં એક વિશિષ્ટ સ્ટેક હતું: 2008 થી કોલ્ડફ્યુઝન અને SQL સર્વર. કોલ્ડફ્યુઝન, જો તમને ખબર ન હોય, અને સંભવતઃ તમે જાણતા ન હોવ, તો એ એન્ટરપ્રાઇઝ PHP છે જે 90 ના દાયકાના મધ્યમાં બહાર આવ્યું હતું, અને ત્યારથી મેં તેના વિશે સાંભળ્યું પણ નથી. ત્યાં પણ હતા: રૂબી, MySQL, PostgreSQL, Java, Go, Python. પરંતુ મુખ્ય મોનોલિથ કોલ્ડફ્યુઝન અને SQL સર્વર પર ચાલી હતી.

સમસ્યાઓ

મેં કંપનીના કર્મચારીઓ સાથે કામ વિશે અને કઈ સમસ્યાઓનો સામનો કરવો પડ્યો તે વિશે જેટલી વધુ વાત કરી, એટલું જ મને સમજાયું કે સમસ્યાઓ માત્ર તકનીકી જ નથી. ઠીક છે, તકનીક જૂની છે - અને તેઓએ તેના પર કામ કર્યું ન હતું, પરંતુ ટીમ અને પ્રક્રિયાઓ સાથે સમસ્યાઓ હતી, અને કંપનીએ આ સમજવાનું શરૂ કર્યું.

પરંપરાગત રીતે, તેમના ટેકીઓ ખૂણામાં બેસીને કોઈ પ્રકારનું કામ કરતા હતા. પરંતુ વધુ અને વધુ વ્યવસાય ડિજિટલ સંસ્કરણ દ્વારા જવા લાગ્યો. તેથી, મેં કામ કરવાનું શરૂ કર્યું તે પહેલાંના છેલ્લા વર્ષમાં, કંપનીમાં નવા લોકો દેખાયા: બોર્ડ ઑફ ડિરેક્ટર્સ, CTO, CPO અને QA ડિરેક્ટર. એટલે કે કંપનીએ ટેક્નોલોજી સેક્ટરમાં રોકાણ કરવાનું શરૂ કર્યું.

ભારે વારસાના નિશાન ફક્ત સિસ્ટમ્સમાં જ ન હતા. કંપનીમાં લેગસી પ્રક્રિયાઓ, વારસાગત લોકો, વારસાગત સંસ્કૃતિ હતી. આ બધું બદલવું હતું. મેં વિચાર્યું કે તે ચોક્કસપણે કંટાળાજનક નહીં હોય, અને તેને અજમાવવાનું નક્કી કર્યું.

બે દિવસ પહેલા

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

શેડ્યૂલ દ્વારા અભિપ્રાય આપતા, કંઈક સ્પષ્ટ રીતે થયું, અને તે શું સ્પષ્ટ નથી. તે બહાર આવ્યું છે કે સમસ્યા ડેટા સેન્ટરમાં નેટવર્ક લેટન્સી હતી: ડેટા સેન્ટરમાં 5 ms લેટન્સી વપરાશકર્તાઓ માટે 2 s માં ફેરવાઈ ગઈ. મને ખબર નથી કે આ કેમ થયું, પરંતુ કોઈ પણ સંજોગોમાં તે જાણીતું બન્યું કે સમસ્યા ડેટા સેન્ટરમાં હતી.

પ્રથમ દિવસ

બે દિવસ વીતી ગયા અને મારા કામના પ્રથમ દિવસે મને ખબર પડી કે સમસ્યા દૂર થઈ નથી.

બે દિવસ માટે, વપરાશકર્તાઓના પૃષ્ઠો સરેરાશ 4 સેકન્ડમાં લોડ થાય છે. હું પૂછું છું કે શું તેઓને સમસ્યા શું છે.

- હા, અમે ટિકિટ ખોલી.
- અને?
- સારું, તેઓએ હજી સુધી અમને જવાબ આપ્યો નથી.

પછી મને સમજાયું કે મને જે વિશે પહેલા કહેવામાં આવ્યું હતું તે બધું જ આઇસબર્ગની એક નાની ટોચ હતી જેના માટે મારે લડવાનું હતું.

એક સારું અવતરણ છે જે આને ખૂબ જ સારી રીતે બંધબેસે છે:

"કેટલીકવાર ટેક્નોલોજી બદલવા માટે તમારે સંસ્થા બદલવી પડે છે."

પરંતુ મેં વર્ષના સૌથી વ્યસ્ત સમયે કામ શરૂ કર્યું હોવાથી, મારે સમસ્યાના ઉકેલ માટે બંને વિકલ્પો જોવાના હતા: ઝડપી અને લાંબા ગાળાના બંને. અને હમણાં જે જટિલ છે તેની સાથે પ્રારંભ કરો.

ત્રણ દિવસ

તેથી, લોડિંગ 4 સેકન્ડ સુધી ચાલે છે, અને 13 થી 15 સૌથી મોટા શિખરો.

આ સમયગાળા દરમિયાન ત્રીજા દિવસે, ડાઉનલોડ ઝડપ આના જેવી દેખાતી હતી:

મારા દૃષ્ટિકોણથી, કંઈપણ કામ કરતું નથી. બીજા બધાના દૃષ્ટિકોણથી તે સામાન્ય કરતાં થોડી ધીમી ચાલી રહી હતી. પરંતુ તે આવું થતું નથી - તે એક ગંભીર સમસ્યા છે.

મેં ટીમને સમજાવવાનો પ્રયાસ કર્યો, જેના જવાબમાં તેઓએ કહ્યું કે તેમને ફક્ત વધુ સર્વરની જરૂર છે. આ, અલબત્ત, સમસ્યાનો ઉકેલ છે, પરંતુ તે હંમેશા એકમાત્ર અને સૌથી અસરકારક નથી. મેં પૂછ્યું કે ત્યાં પર્યાપ્ત સર્વર કેમ નથી, ટ્રાફિકનું પ્રમાણ શું છે. મેં ડેટા એક્સ્ટ્રાપોલેટ કર્યો અને જાણવા મળ્યું કે અમારી પાસે પ્રતિ સેકન્ડ અંદાજે 150 વિનંતીઓ છે, જે, સૈદ્ધાંતિક રીતે, વાજબી મર્યાદામાં આવે છે.

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

— મને પૂછવામાં શરમ આવે છે, પણ 150 ને 17 વડે ભાગ્યા તો લગભગ 8 મળે? શું તમે એમ કહો છો કે દરેક સર્વર સેકન્ડ દીઠ 8 વિનંતીઓને મંજૂરી આપે છે, અને જો આવતીકાલે પ્રતિ સેકન્ડમાં 160 વિનંતીઓ આવે, તો અમને 2 વધુ સર્વરની જરૂર પડશે?

અલબત્ત, અમને વધારાના સર્વરની જરૂર નથી. ઉકેલ કોડમાં જ હતો, અને સપાટી પર:

var currentClass = classes.getCurrentClass();
return currentClass;

એક ફંકશન હતું getCurrentClass(), કારણ કે સાઇટ પરની દરેક વસ્તુ વર્ગના સંદર્ભમાં કાર્ય કરે છે - તે સાચું છે. અને આ માટે દરેક પૃષ્ઠ પર એક કાર્ય હતું 200+ વિનંતીઓ.

આ રીતે ઉકેલ ખૂબ જ સરળ હતો, તમારે કંઈપણ ફરીથી લખવાની પણ જરૂર ન હતી: ફક્ત તે જ માહિતી ફરીથી પૂછશો નહીં.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

હું ખૂબ જ ખુશ હતો કારણ કે મેં નક્કી કર્યું કે ત્રીજા દિવસે જ મને મુખ્ય સમસ્યા મળી ગઈ હતી. હું જેવો નિષ્કપટ હતો, આ ઘણી સમસ્યાઓમાંથી એક હતી.

પરંતુ આ પ્રથમ સમસ્યા ઉકેલવાથી ગ્રાફ ઘણો નીચો ગયો.

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

દિવસ દસ

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

ફરીથી કંઈક રસપ્રદ જાણવા મળ્યું. ટીમમાં આનો સમાવેશ થાય છે: 18 વિકાસકર્તાઓ; 8 પરીક્ષકો; 3 મેનેજરો; 2 આર્કિટેક્ટ. અને તેઓ બધાએ સામાન્ય ધાર્મિક વિધિઓમાં ભાગ લીધો, એટલે કે, દરરોજ સવારે 30 થી વધુ લોકો સ્ટેન્ડ-અપ પર આવ્યા અને તેઓએ શું કર્યું તે કહ્યું. તે સ્પષ્ટ છે કે મીટિંગમાં 5 કે 15 મિનિટનો સમય નહોતો. કોઈએ કોઈનું સાંભળ્યું નહીં કારણ કે દરેક વ્યક્તિ જુદી જુદી સિસ્ટમ પર કામ કરે છે. આ ફોર્મમાં, માવજત સત્ર માટે પ્રતિ કલાક 2-3 ટિકિટ પહેલેથી જ સારું પરિણામ હતું.

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

પરિણામે અમને મળ્યું:

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

અમે મુખ્યત્વે કાર્યક્ષમતા, ઉત્પાદકતા અને ગુણવત્તા પર ધ્યાન કેન્દ્રિત કર્યું - આ તે સમસ્યાઓ છે જે અમે ટીમના પરિવર્તન સાથે ઉકેલવાનો પ્રયાસ કર્યો છે.

અગિયારમો દિવસ

ટીમનું માળખું બદલવાની પ્રક્રિયામાં, મેં કેવી રીતે ગણતરી કરવી તે શોધ્યું સ્ટોરીપોઇંટ્સ. 1 SP એક દિવસ સમાન હતો, અને દરેક ટિકિટમાં વિકાસ અને QA બંને માટે SP હોય છે, એટલે કે ઓછામાં ઓછા 2 SP.

મેં આ કેવી રીતે શોધ્યું?

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

આ પછી અમે:

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

વીસમો દિવસ

પ્રથમ મહિનાના મધ્યમાં ક્યાંક, પરિસ્થિતિ થોડી સ્થિર થઈ, મને સમજાયું કે મૂળભૂત રીતે શું થઈ રહ્યું છે, અને પહેલેથી જ ભવિષ્યમાં જોવાનું અને લાંબા ગાળાના ઉકેલો વિશે વિચારવાનું શરૂ કર્યું.

લાંબા ગાળાના લક્ષ્યો:

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

ભૂતકાળમાં તે વારંવાર કહેવામાં આવતું હતું: "ચાલો બધું [ભાષા/ફ્રેમવર્ક] માં ફરીથી લખીએ, બધું સારું કામ કરશે!"

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

• પ્રોજેક્ટના મિશન અને લક્ષ્યોને પ્રતિબિંબિત કરે છે;
• મુખ્ય લક્ષ્યોને પ્રાધાન્ય આપે છે;
• તેમને હાંસલ કરવા માટેનું શેડ્યૂલ સમાવે છે.

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

એટલે કે, સંગઠનાત્મક KPIs ને ટીમો દ્વારા સમર્થન આપવામાં આવે છે, અને ટીમ KPIs ને વ્યક્તિગત KPIs દ્વારા સમર્થન આપવામાં આવે છે. નહિંતર, જો તકનીકી KPIs સંગઠનાત્મક સાથે સુસંગત ન હોય, તો પછી દરેક જણ પોતાના પર ધાબળો ખેંચે છે.

ઉદાહરણ તરીકે, સંગઠનાત્મક KPIsમાંથી એક નવા ઉત્પાદનો દ્વારા બજારહિસ્સો વધારી રહ્યું છે.

તમે વધુ નવા ઉત્પાદનો રાખવાના લક્ષ્યને કેવી રીતે સમર્થન આપી શકો?

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

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

આમ, પુનઃલેખન કોડ સહિત દરેક નિર્ણય, કંપનીએ અમારા માટે નિર્ધારિત કરેલા ચોક્કસ લક્ષ્યોને સમર્થન આપવું આવશ્યક છે (સંસ્થાકીય વૃદ્ધિ, નવી સુવિધાઓ, ભરતી).

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

ત્રીસમો દિવસ

મહિનાના અંતે, મને બીજી એક ઘોંઘાટ મળી: મારી ઓપ્સ ટીમ પરના કોઈએ ક્યારેય ક્લાયન્ટ્સ સાથે જે કોન્ટ્રાક્ટમાં પ્રવેશ કર્યો છે તે જોયો નથી. તમે પૂછી શકો છો કે તમારે શા માટે સંપર્કો જોવાની જરૂર છે.

• સૌપ્રથમ, કારણ કે SLAs કરારમાં ઉલ્લેખિત છે.
• બીજું, SLA બધા અલગ છે. દરેક ક્લાયંટ તેની પોતાની જરૂરિયાતો સાથે આવ્યો હતો, અને વેચાણ વિભાગે જોયા વગર સહી કરી હતી.

અન્ય એક રસપ્રદ સૂક્ષ્મતા એ છે કે સૌથી મોટા ક્લાયન્ટમાંના એક સાથેનો કરાર જણાવે છે કે પ્લેટફોર્મ દ્વારા સપોર્ટેડ તમામ સોફ્ટવેર વર્ઝન n-1 હોવા જોઈએ, એટલે કે લેટેસ્ટ વર્ઝન નહીં, પરંતુ અંતિમ સંસ્કરણ હોવું જોઈએ.

તે સ્પષ્ટ છે કે જો પ્લેટફોર્મ ColdFusion અને SQL સર્વર 1 પર આધારિત હોય તો અમે n-2008થી કેટલા દૂર હતા, જે હવે જુલાઈમાં બિલકુલ સમર્થિત ન હતું.

પિસ્તાલીસમો દિવસ

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

તમે પ્રક્રિયાને નાના ટુકડાઓમાં તોડી નાખો અને જુઓ કે શું ઘણો સમય લે છે, શું ઑપ્ટિમાઇઝ કરી શકાય છે, સુધારી શકાય છે, વગેરે. ઉદાહરણ તરીકે, ઉત્પાદનની વિનંતીને ગ્રૂમિંગમાંથી પસાર થવામાં કેટલો સમય લાગે છે, વિકાસકર્તા લઈ શકે તેવી ટિકિટ ક્યારે પહોંચે છે, QA વગેરે. તેથી તમે દરેક વ્યક્તિગત પગલાને વિગતવાર જુઓ અને શું ઑપ્ટિમાઇઝ કરી શકાય તે વિશે વિચારો.

જ્યારે મેં આ કર્યું, ત્યારે બે વસ્તુઓ મારી નજરમાં આવી:

• QA થી વિકાસકર્તાઓને પરત કરાયેલી ટિકિટોની ઊંચી ટકાવારી;
• પુલ વિનંતી સમીક્ષાઓ ખૂબ લાંબો લીધો.

સમસ્યા એ હતી કે આ તારણો હતા જેમ કે: તેમાં ઘણો સમય લાગે છે, પરંતુ અમને ખાતરી નથી કે કેટલો સમય.

"તમે જે માપી શકતા નથી તેને સુધારી શકતા નથી."

સમસ્યા કેટલી ગંભીર છે તેનું સમર્થન કેવી રીતે કરવું? શું તે દિવસો કે કલાકો બગાડે છે?

આને માપવા માટે, અમે જીરા પ્રક્રિયામાં થોડાં પગલાં ઉમેર્યાં છે: દરેક ટિકિટ કેટલા સમય સુધી રાહ જુએ છે અને તે ચોક્કસ સ્ટેપ પર કેટલી વાર પાછી આવે છે તે માપવા માટે "દેવ માટે તૈયાર" અને "QA માટે તૈયાર".

સમીક્ષા માટે સરેરાશ કેટલી ટિકિટો છે તે જાણવા માટે અમે "સમીક્ષામાં" પણ ઉમેર્યું છે અને તેમાંથી તમે નૃત્ય કરવાનું શરૂ કરી શકો છો. અમારી પાસે સિસ્ટમ મેટ્રિક્સ હતી, હવે અમે નવા મેટ્રિક્સ ઉમેર્યા અને માપવાનું શરૂ કર્યું:

• પ્રક્રિયા કાર્યક્ષમતા: કામગીરી અને આયોજિત/વિતરિત.
• પ્રક્રિયા ગુણવત્તા: ખામીઓની સંખ્યા, QA માંથી ખામી.

તે ખરેખર સમજવામાં મદદ કરે છે કે શું સારું થઈ રહ્યું છે અને શું સારું નથી થઈ રહ્યું.

પચાસમો દિવસ

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

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

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

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

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

એકાવન દિવસ

મારી પાસે કોણ છે તે સમજવા માટે મેં ટીમને નજીકથી જોવાનું શરૂ કર્યું, અને ફરી એકવાર મને યાદ આવ્યું:

"મોટાભાગની સમસ્યાઓ લોકોની સમસ્યાઓ છે."

મને જાણવા મળ્યું છે કે ટીમમાં - દેવ અને ઓપ્સ બંને - ત્રણ મોટી સમસ્યાઓ ધરાવે છે:

• વર્તમાન સ્થિતિથી સંતોષ.
• જવાબદારીનો અભાવ - કારણ કે વ્યવસાયને પ્રભાવિત કરવા માટે કોઈએ ક્યારેય કલાકારોના કાર્યના પરિણામો લાવ્યા નથી.
• પરિવર્તનનો ડર.

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

પરંતુ તમે કંઈપણ બદલ્યા વિના સારી રીતે મેળવી શકતા નથી.

મેં એક કર્મચારી સાથે એકદમ વાહિયાત વાતચીત કરી, મેં તેને ઓપ્ટિમાઇઝેશન માટેના મારા વિચારો કહ્યું, જેના માટે તેણે મને કહ્યું:
- ઓહ, ગયા વર્ષે અમારી પાસે શું હતું તે તમે જોયું નથી!
- તો શું?
"હવે તે પહેલા કરતા ઘણું સારું છે."
- તો, તે વધુ સારું ન થઈ શકે?
- શેના માટે?

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

• 12 સેકન્ડ લોડિંગ;
• દરેક પ્રકાશનમાં 5-10 મિનિટનો ડાઉનટાઇમ;
• જટિલ સમસ્યાઓના નિવારણમાં દિવસો અને અઠવાડિયા લાગે છે;
• ફરજ કર્મચારીઓનો અભાવ 24x7 / ઓન-કોલ.

કોઈએ ક્યારેય પૂછવાનો પ્રયાસ કર્યો નથી કે શા માટે આપણે તે વધુ સારું નથી કરતા, અને કોઈને ક્યારેય સમજાયું નથી કે આ રીતે ન હોવું જોઈએ.

બોનસ તરીકે, એક વધુ સમસ્યા હતી: અનુભવનો અભાવ. વરિષ્ઠો ચાલ્યા ગયા, અને બાકીની યુવા ટીમ પાછલા શાસન હેઠળ ઉછર્યા અને તેના દ્વારા ઝેર થઈ ગયું.

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

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

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

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

જવાબમાં, મેં નીચેની પદ્ધતિઓ રજૂ કરી:

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

સાઠમો દિવસ

જ્યારે હું આ બધું કરી રહ્યો હતો, ત્યારે બજેટનો આંકડો કાઢવાનો સમય આવી ગયો હતો. અલબત્ત, અમે અમારા પૈસા ક્યાં ખર્ચ્યા તેમાં મને ઘણી રસપ્રદ વસ્તુઓ મળી. ઉદાહરણ તરીકે, અમારી પાસે એક FTP સર્વર સાથે એક અલગ ડેટા સેન્ટરમાં એક આખો રેક હતો, જેનો ઉપયોગ એક ક્લાયન્ટ દ્વારા થતો હતો. તે બહાર આવ્યું કે "... અમે સ્થળાંતર કર્યું, પરંતુ તે તેવો જ રહ્યો, અમે તેને બદલ્યો નથી." તે 2 વર્ષ પહેલા હતું.

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

પરંતુ વિકાસકર્તાઓ પાસે સર્વર ખરીદવાનો અનુભવ અને સર્વર્સનું જરૂરી કદ નક્કી કરવાની કુશળતા નથી, કારણ કે તેમને પહેલા તેની જરૂર નહોતી. અને તેઓ સામાન્ય રીતે માપનીયતા અને પ્રદર્શન વચ્ચેનો તફાવત સમજી શકતા નથી.

ઇન્વેન્ટરી પરિણામો:

• અમે એ જ ડેટા સેન્ટર છોડી દીધું.
• અમે 3 લોગ સેવાઓ સાથેનો કરાર સમાપ્ત કર્યો. કારણ કે અમારી પાસે તેમાંથી 5 હતા - દરેક ડેવલપરે જેમણે કંઈક સાથે રમવાનું શરૂ કર્યું એક નવું લીધું.
• 7 AWS સિસ્ટમ બંધ કરવામાં આવી હતી. ફરીથી, કોઈએ મૃત પ્રોજેક્ટ્સને રોક્યા નહીં; તેઓ બધા કામ કરવાનું ચાલુ રાખ્યું.
• સોફ્ટવેર ખર્ચમાં 6 ગણો ઘટાડો કર્યો.

પંચોતેર દિવસ

સમય વીતતો ગયો, અને અઢી મહિનામાં મારે બોર્ડ ઓફ ડિરેક્ટર્સ સાથે મળવાનું થયું. અમારું બોર્ડ ઑફ ડિરેક્ટર્સ અન્ય કરતાં વધુ સારું કે ખરાબ નથી; બધા ડિરેક્ટર્સ બોર્ડની જેમ, તે બધું જાણવા માંગે છે. લોકો નાણાંનું રોકાણ કરે છે અને અમે જે કરીએ છીએ તે KPIsમાં કેટલું બંધબેસે છે તે સમજવા માંગે છે.

બોર્ડ ઓફ ડિરેક્ટર્સ દર મહિને ઘણી બધી માહિતી મેળવે છે: વપરાશકર્તાઓની સંખ્યા, તેમની વૃદ્ધિ, તેઓ કઈ સેવાઓનો ઉપયોગ કરે છે અને કેવી રીતે, પ્રદર્શન અને ઉત્પાદકતા અને અંતે, સરેરાશ પૃષ્ઠ લોડિંગ ઝડપ.

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

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

એટલે કે, ColdFusion જેટ્ટી અને nginxમાંથી પસાર થાય છે અને પૃષ્ઠોને લોન્ચ કરે છે. અને છબીઓ, JS અને CSS તેમના પોતાના રૂપરેખાંકનો સાથે અલગ nginxમાંથી પસાર થાય છે. આ એકદમ પ્રમાણભૂત પ્રથા છે જેના વિશે હું વાત કરી રહ્યો છું લખ્યું થોડા વર્ષો પહેલા. પરિણામે, ચિત્રો વધુ ઝડપથી લોડ થાય છે, અને... સરેરાશ લોડિંગ ઝડપ 200 ms વધી છે.

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

પંચ્યાસી દિવસ

ત્રીજા મહિનાના અંતે, મને સમજાયું કે એક એવી વસ્તુ હતી જેના પર મેં બિલકુલ ગણતરી નહોતી કરી: સમય. મેં જે વિશે વાત કરી તે બધું સમય લે છે.

આ મારું વાસ્તવિક સાપ્તાહિક કેલેન્ડર છે - માત્ર એક કામનું અઠવાડિયું, બહુ વ્યસ્ત નથી. દરેક વસ્તુ માટે પૂરતો સમય નથી. તેથી, ફરીથી, તમારે એવા લોકોની ભરતી કરવાની જરૂર છે જે તમને સમસ્યાઓનો સામનો કરવામાં મદદ કરશે.

નિષ્કર્ષ

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

ત્યાં એક મિલિયન વધુ સમાન વસ્તુઓ હતી જેના વિશે આપણે લાંબા સમય સુધી વાત કરી શકીએ છીએ. પરંતુ સૌથી મહત્વની બાબત જે હજુ કહેવાની જરૂર છે તે સંસ્કૃતિ છે.

તે સંસ્કૃતિ અથવા તેનો અભાવ છે જે અન્ય તમામ સમસ્યાઓ તરફ દોરી જાય છે. અમે એવી સંસ્કૃતિ બનાવવાનો પ્રયાસ કરી રહ્યા છીએ જ્યાં લોકો:

• નિષ્ફળતાથી ડરતા નથી;
• ભૂલોમાંથી શીખો;
• અન્ય ટીમો સાથે સહયોગ;
• પહેલ કરો;
• જવાબદારી લેવી;
• ધ્યેય તરીકે પરિણામનું સ્વાગત કરો;
• સફળતાની ઉજવણી.

આ સાથે બીજું બધું આવશે.

લિયોન ફાયર ટ્વિટર પર, ફેસબુક અને પર માધ્યમ.

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

સોર્સ: www.habr.com