અનાથ સેવાઓ: (માઇક્રો) સર્વિસ આર્કિટેક્ચરનું નુકસાન

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

કટની નીચે રિપોર્ટનું ટેક્સ્ટ વર્ઝન છે.

હેલો સાથીદારો! મારું નામ આન્દ્રે છે, હું Banki.ru પર ઓપરેશનનું નેતૃત્વ કરું છું.

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

સેવાઓના ફાયદા

હું ઝડપથી સેવાઓના ફાયદાઓ પર જઈશ.

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

બીજું, આઇસોલેટેડ ડેવલપમેન્ટ, જ્યારે તમારી પાસે ઘણી ડેવલપમેન્ટ ટીમો હોય, દરેક ટીમમાં વિવિધ ડેવલપર્સ હોય અને દરેક ટીમ તેની પોતાની સર્વિસ ડેવલપ કરે.

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

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

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

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

ઉદાહરણ તરીકે, તમારી પાસે 20 સેવાઓ છે અને તમારે હાથથી જમાવવાની જરૂર છે, તમારી પાસે 20 કન્સોલ છે, અને તમે એક સાથે નીન્જાની જેમ "એન્ટર" દબાવો છો. તે બહુ સારું નથી.

જો તમારી પાસે પરીક્ષણ પછી કોઈ સેવા છે (જો ત્યાં પરીક્ષણ છે, અલબત્ત), અને તમારે હજી પણ તેને ફાઇલ સાથે સમાપ્ત કરવાની જરૂર છે જેથી તે ઉત્પાદનમાં કાર્ય કરે, તો મારી પાસે તમારા માટે ખરાબ સમાચાર પણ છે.

જો તમે ચોક્કસ એમેઝોન સેવાઓ પર આધાર રાખો છો અને રશિયામાં કામ કરો છો, તો બે મહિના પહેલા તમારી પાસે "આજુબાજુની દરેક વસ્તુ આગમાં છે, હું ઠીક છું, બધું સરસ છે."

અમે જમાવટને સ્વચાલિત કરવા માટે Ansible નો ઉપયોગ કરીએ છીએ, કન્વર્જન્સ માટે કઠપૂતળીનો, જમાવટને સ્વચાલિત કરવા માટે વાંસનો અને કોઈક રીતે તે બધાનું વર્ણન કરવા માટે સંગમનો ઉપયોગ કરીએ છીએ.

હું આના પર વિગતવાર ધ્યાન આપીશ નહીં, કારણ કે અહેવાલ ક્રિયાપ્રતિક્રિયા પ્રથાઓ વિશે વધુ છે, અને તકનીકી અમલીકરણ વિશે નહીં.

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

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

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

ઠીક છે, ત્યાં વિરોધાભાસી અવલંબન છે, જ્યારે પ્રોજેક્ટનો એક ભાગ એક સંસ્કરણની લાઇબ્રેરી પર આધાર રાખે છે, પ્રોજેક્ટનો બીજો ભાગ બીજા સંસ્કરણ પર આધાર રાખે છે, અને લાઇબ્રેરીઓ એકસાથે ઇન્સ્ટોલ કરેલી નથી.

અમારી પાસે PHP 5.6 માં સાઇટ્સ અને સેવાઓ છે, અમને તેમની શરમ આવે છે, પરંતુ અમે શું કરી શકીએ? આ અમારી એક સાઈટ છે. PHP 7 પર સાઇટ્સ અને સેવાઓ છે, તેમાંની વધુ છે, અમને તેમાં શરમ નથી. અને દરેક વિકાસકર્તાનો પોતાનો આધાર હોય છે જ્યાં તે ખુશીથી જોતો હોય છે.

જો તમે કંપનીમાં એક ભાષામાં લખો છો, તો વિકાસકર્તા દીઠ ત્રણ વર્ચ્યુઅલ મશીન સામાન્ય લાગે છે. જો તમારી પાસે વિવિધ પ્રોગ્રામિંગ ભાષાઓ છે, તો પરિસ્થિતિ વધુ ખરાબ થાય છે.

તમારી પાસે આના પર સાઇટ્સ અને સેવાઓ છે, આના પર, પછી Go માટે બીજી સાઇટ, Ruby માટે એક સાઇટ અને બાજુમાં કેટલીક અન્ય Redis છે. પરિણામે, આ બધું સમર્થન માટે એક વિશાળ ક્ષેત્રમાં ફેરવાય છે, અને હંમેશાં તેમાંથી કેટલાક તૂટી શકે છે.

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

દરેક સેવાની પોતાની ટીમ હોય છે

અમારો મુખ્ય ફાયદો, જે ઘણા વર્ષોથી સ્ફટિકીકૃત થયો છે, તે એ છે કે દરેક સેવાની પોતાની ટીમ હોય છે. મોટા પ્રોજેક્ટ માટે આ અનુકૂળ છે, તમે દસ્તાવેજીકરણ પર સમય બચાવી શકો છો, મેનેજરો તેમના પ્રોજેક્ટને સારી રીતે જાણે છે.

તમે સપોર્ટથી સરળતાથી કાર્યો સબમિટ કરી શકો છો. ઉદાહરણ તરીકે, વીમા સેવા તૂટી ગઈ. અને તરત જ વીમા સાથે કામ કરતી ટીમ તેને ઠીક કરવા જાય છે.

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

અને જ્યારે તમે તમારી સેવાનો ભંગ કરો છો, અને આ અનિવાર્યપણે થાય છે, ત્યારે તમે અન્ય લોકોની સેવાઓને અસર કરી નથી, અને અન્ય ટીમોના વિકાસકર્તાઓ તમારી પાસે બિટ્સ લઈને આવતા નથી અને કહે છે: "અય-એ, તે કરશો નહીં."

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

જો ટીમો તરતી હોય (અમે પણ ક્યારેક તેનો ઉપયોગ કરીએ છીએ), તો "સ્ટાર મેપ" તરીકે ઓળખાતી એક સારી પદ્ધતિ છે.

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

અનાથ સેવાઓ કેવી રીતે દેખાય છે?

પ્રથમ સમસ્યા, તમારા ઈન્ફ્રાસ્ટ્રક્ચરમાં અનાથ સેવા મેળવવાનો પ્રથમ રસ્તો લોકોને નોકરીમાંથી કાઢી મૂકવો છે. કાર્યોનું મૂલ્યાંકન કરવામાં આવે તે પહેલાં શું કોઈએ ક્યારેય વ્યવસાય પૂર્ણ કરવાની સમયમર્યાદા મેળવી છે? કેટલીકવાર એવું બને છે કે સમયમર્યાદા ચુસ્ત હોય છે અને દસ્તાવેજીકરણ માટે પૂરતો સમય નથી. "અમારે ઉત્પાદનને સેવા સોંપવાની જરૂર છે, પછી અમે તેને ઉમેરીશું."

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

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

અનાથ કેવી રીતે ઓળખવો?

આ સૂચિ પરિસ્થિતિનું સારી રીતે વર્ણન કરે છે. તેમના ઈન્ફ્રાસ્ટ્રક્ચર વિશે કોણ કંઈ શીખ્યું?

દસ્તાવેજીકૃત વર્ક-અરાઉન્ડ વિશે: ત્યાં એક સેવા છે અને, સામાન્ય રીતે, તે કાર્ય કરે છે, તેની સાથે કેવી રીતે કામ કરવું તે અંગેની બે-પૃષ્ઠ માર્ગદર્શિકા છે, પરંતુ તે અંદર કેવી રીતે કાર્ય કરે છે તે કોઈ જાણતું નથી.

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

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

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

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

ઉદાહરણ તરીકે, અમારી પાસે એવી સેવા હતી જેમાં વિવિધ અણધાર્યા સ્થળોએ સ્ફીન્ક્સ હતું. મારે શું કરવાનું હતું તે હું તમને પછી કહીશ.

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

હું કેપ્ટન તરીકે ચાલુ રહીશ. આઉટસોર્સ સેવા સ્વીકારવી એ ફરજિયાત પ્રક્રિયા છે. શું કોઈએ ક્યારેય આઉટસોર્સ કરેલી સેવા આવી હોય અને ક્યાંય સ્વીકારવામાં ન આવે? આ અલબત્ત, અનાથ સેવા તરીકે લોકપ્રિય નથી, પરંતુ હજી પણ.

સેવાને તપાસવાની જરૂર છે, સેવાની સમીક્ષા કરવાની જરૂર છે, પાસવર્ડ બદલવાની જરૂર છે. અમારી પાસે એક કેસ હતો જ્યારે તેઓએ અમને સેવા આપી, ત્યાં એક એડમિન પેનલ છે “જો લોગીન == 'એડમિન' && પાસવર્ડ == 'એડમિન'...”, તે કોડમાં જ લખેલું છે. અમે બેસીને વિચારીએ છીએ, અને લોકો આ 2018 માં લખે છે?

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

સુધારણા માટે સેવા મોકલવામાં કોઈ શરમ ન હોવી જોઈએ. જ્યારે તમે કહો: "અમે આ સેવા સ્વીકારીશું નહીં, અમારી પાસે 20 કાર્યો છે, તે કરો, પછી અમે સ્વીકારીશું," આ સામાન્ય છે. તમારા અંતઃકરણને એ હકીકતથી ઠેસ ન પહોંચાડવી જોઈએ કે તમે મેનેજરને સેટ કરી રહ્યા છો અથવા વ્યવસાયમાં પૈસાનો બગાડ થઈ રહ્યો છે. વ્યવસાય પછી વધુ ખર્ચ કરશે.

અમારી પાસે એક કેસ હતો જ્યારે અમે પાયલોટ પ્રોજેક્ટને આઉટસોર્સ કરવાનું નક્કી કર્યું.

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

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

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

અનાથ સાથે શું સમસ્યા છે?

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

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

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

શા માટે અનાથ સેવાઓ જોખમી છે:

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

અનાથ સેવાઓનું શું કરવું?

હું ફરીથી શું કરવું તે પુનરાવર્તન કરીશ. પ્રથમ, દસ્તાવેજીકરણ હોવું આવશ્યક છે. Banki.ru પર 7 વર્ષોએ મને શીખવ્યું કે પરીક્ષકોએ વિકાસકર્તાઓની વાત ન લેવી જોઈએ, અને કામગીરીએ દરેકની વાત ન લેવી જોઈએ. આપણે તપાસ કરવાની જરૂર છે.

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

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

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

અનાથ સેવા સાથે કામ કરવાની યોજના

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

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

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

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

અમારી પાસે એવી પરિસ્થિતિ હતી જ્યારે અમે Yii 1 પર સેવા લીધી અને સમજાયું કે અમે તેને વધુ વિકસિત કરી શકતા નથી, કારણ કે અમારી પાસે એવા વિકાસકર્તાઓ નથી કે જેઓ Yii 1 પર સારી રીતે લખી શકે. બધા વિકાસકર્તાઓ Symfony XNUMX પર સારું લખે છે. શુ કરવુ? અમે સમય ફાળવ્યો, એક ટીમ ફાળવી, મેનેજરની ફાળવણી કરી, પ્રોજેક્ટ ફરીથી લખ્યો અને તેના પર ટ્રાફિકને સરળતાથી ફેરવ્યો.

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

આ તે જ છે જેના વિશે મારે વાત કરવી છે, હું ચર્ચા કરવા તૈયાર છું, વિષય હોલીવર છે, ઘણા તેમાં તરી ગયા છે.

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

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

અમે હાલમાં Node.js પર સેવા બનાવી રહ્યા છીએ, અને દરેક ડેવલપર માટે અલગ ભાષા સાથે આ માત્ર નજીકનું પ્લેટફોર્મ હશે. પરંતુ અમે બેઠા અને વિચાર્યું કે આ રમત મીણબત્તીની કિંમતની છે. એટલે કે, આ તમારા માટે બેસીને વિચારવાનો પ્રશ્ન છે.

તમે તમારી સેવાઓનું નિરીક્ષણ કેવી રીતે કરશો? તમે લોગ કેવી રીતે એકત્રિત અને મોનિટર કરો છો?

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

એક જ વાતાવરણમાં પપેટ અને એન્સિબલ સાથે કેવી રીતે જીવવું?

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

તમે સુસંગતતા કેવી રીતે જાળવી શકો છો? શું તમારી પાસે Ansible અને Puppet બંનેમાં રૂપરેખાઓ છે?

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

પ્રેઝન્ટેશન રૂબીના વિવિધ વર્ઝન વિશે હતું. શું ઉકેલ?

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

આ વર્ષની કોન્ફરન્સ DevOpsDays મોસ્કો 7 ડિસેમ્બરે ટેક્નોપોલિસ ખાતે યોજાશે. અમે 11 નવેમ્બર સુધી રિપોર્ટ્સ માટેની અરજીઓ સ્વીકારી રહ્યા છીએ. લખો જો તમે બોલવા માંગતા હોવ તો અમને.

સહભાગીઓ માટે નોંધણી ખુલ્લી છે, અમારી સાથે જોડાઓ!

સોર્સ: www.habr.com