ડેવલપર્સ મંગળના છે, એડમિન શુક્રના છે

સંયોગો રેન્ડમ છે, અને ખરેખર તે બીજા ગ્રહ પર હતો ...

બેકએન્ડ ડેવલપર એડમિન્સ સાથેની ટીમમાં કેવી રીતે કામ કરે છે તે વિશે હું ત્રણ સફળતા અને નિષ્ફળતાની વાર્તાઓ શેર કરવા માંગુ છું.

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

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

- ઉચ્ચ જવાબદારી.
- ઉત્પાદન તૂટવાનું જોખમ.
- તમામ ક્ષેત્રોમાં સારા નિષ્ણાત બનવું મુશ્કેલ છે.

રસ નથી, ચાલો આગળ વધીએ

બીજી વાર્તા.
મોટી કંપની, મોટો પ્રોજેક્ટ. 5-7 કર્મચારીઓ અને ઘણા વિકાસ જૂથો સાથે વહીવટ વિભાગ છે. જ્યારે તમે આવી કંપનીમાં કામ કરવા આવો છો, ત્યારે દરેક એડમિન વિચારે છે કે તમે અહીં કોઈ પ્રોડક્ટ પર કામ કરવા નથી આવ્યા, પરંતુ કંઈક તોડવા આવ્યા છો. ન તો સહી કરેલ NDA કે ઇન્ટરવ્યુમાં પસંદગી અન્યથા સૂચવે છે. ના, આ માણસ અમારા ચુંબન ઉત્પાદનને બરબાદ કરવા માટે તેના ગંદા હાથો સાથે અહીં આવ્યો છે. તેથી, આવી વ્યક્તિ સાથે તમારે ઓછામાં ઓછા સંદેશાવ્યવહારની જરૂર છે; ઓછામાં ઓછા, તમે જવાબમાં સ્ટીકર ફેંકી શકો છો. પ્રોજેક્ટ આર્કિટેક્ચર વિશેના પ્રશ્નોના જવાબ આપશો નહીં. જ્યાં સુધી ટીમ લીડ પૂછે નહીં ત્યાં સુધી ઍક્સેસ ન આપવાની સલાહ આપવામાં આવે છે. અને જ્યારે તે પૂછે છે, ત્યારે તે તેમને માંગ્યા કરતાં પણ ઓછા વિશેષાધિકારો સાથે પાછું આપશે. આવા સંચાલકો સાથે લગભગ તમામ સંચાર વિકાસ વિભાગ અને વહીવટ વિભાગ વચ્ચેના બ્લેક હોલ દ્વારા શોષાય છે. સમસ્યાઓનું તાત્કાલિક નિરાકરણ કરવું અશક્ય છે. પરંતુ તમે રૂબરૂ આવી શકતા નથી - સંચાલકો 24/7 ખૂબ વ્યસ્ત છે. (તમે આખો સમય શું કરો છો?) કેટલાક પ્રદર્શન લક્ષણો:

• ઉત્પાદનમાં સરેરાશ જમાવટનો સમય 4-5 કલાક છે
• ઉત્પાદનમાં મહત્તમ જમાવટ સમય 9 કલાક
• ડેવલપર માટે, પ્રોડક્શનમાં એપ્લિકેશન એ પ્રોડક્શન સર્વરની જેમ જ બ્લેક બોક્સ છે. કુલ કેટલા છે?
• પ્રકાશનની ઓછી ગુણવત્તા, વારંવાર ભૂલો
• વિકાસકર્તા પ્રકાશન પ્રક્રિયામાં ભાગ લેતા નથી

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

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

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

અધિનિયમ 3, ટૂંકું
અર્જન્ટ ટિકિટ, કી કાર્યક્ષમતા ઉત્પાદનમાંના એક વપરાશકર્તાઓ માટે કામ કરતી નથી. અમે પોક કરવામાં અને તપાસ કરવામાં થોડા કલાકો પસાર કરીએ છીએ. વિકાસના વાતાવરણમાં, બધું કામ કરે છે. ત્યાં સ્પષ્ટ સમજ છે કે php-fpm લૉગમાં તપાસ કરવી એ સારો વિચાર છે. તે સમયે પ્રોજેક્ટ પર ELK અથવા Prometheus જેવી કોઈ લોગ સિસ્ટમ્સ ન હતી. અમે એડમિનિસ્ટ્રેશન વિભાગને ટિકિટ ખોલીએ છીએ જેથી તેઓ સર્વર પરના php-fpm લૉગની ઍક્સેસ આપે. અહીં તમારે એ સમજવાની જરૂર છે કે અમે એક કારણસર એક્સેસ માટે પૂછી રહ્યા છીએ, શું તમને બ્લેક હોલ અને એડમિન 24/7 વ્યસ્ત રહેવા વિશે યાદ નથી? જો તમે તેમને જાતે જ લૉગ્સ જોવા માટે કહો, તો આ "આ જીવનમાં નથી" પ્રાથમિકતા સાથેનું કાર્ય છે. ટિકિટ બનાવવામાં આવી હતી, અમને વહીવટી વિભાગના વડા તરફથી ત્વરિત પ્રતિસાદ મળ્યો: "તમારે ઉત્પાદન લૉગની ઍક્સેસની જરૂર નથી, ભૂલો વિના લખો." એક પડદો.

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

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

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

અમે શું કર્યું છે?
દરેક પ્રકાશન માટે, પ્રકાશન નોંધોની સૂચિ બનાવવામાં આવી હતી, જેમાં કાર્યની સૂચિ શામેલ છે જે કામ કરવા માટે આગામી પ્રકાશન માટે સર્વર પર કરવાની જરૂર છે. સૂચિમાં ઘણા વિભાગો શામેલ છે, કાર્ય કે જે એડમિનિસ્ટ્રેટર, પ્રકાશન માટે જવાબદાર વ્યક્તિ અને વિકાસકર્તા દ્વારા હાથ ધરવામાં આવવું જોઈએ. વિકાસકર્તાઓને તમામ પ્રોડક્શન સર્વર્સની બિન-રુટ ઍક્સેસ પ્રાપ્ત થઈ, જેણે સામાન્ય રીતે વિકાસને ઝડપી બનાવ્યો અને ખાસ કરીને સમસ્યાનું નિરાકરણ કર્યું. ઉત્પાદન કેવી રીતે કાર્ય કરે છે, તેને કઈ સેવાઓમાં વિભાજિત કરવામાં આવે છે, પ્રતિકૃતિની કિંમત ક્યાં અને કેટલી છે તેની પણ વિકાસકર્તાઓને સમજ હોય ​​છે. કેટલાક લડાઇ લોડ્સ સ્પષ્ટ થઈ ગયા છે, જે નિઃશંકપણે કોડની ગુણવત્તાને અસર કરે છે. પ્રકાશન પ્રક્રિયા દરમિયાન સંચાર ઇન્સ્ટન્ટ મેસેન્જર્સમાંથી એકની ચેટમાં થયો હતો. પ્રથમ, અમારી પાસે બધી ક્રિયાઓનો લોગ હતો, અને બીજું, વાતચીત નજીકના વાતાવરણમાં થઈ હતી. ક્રિયાઓનો ઈતિહાસ એક કરતા વધુ વખત નવા કર્મચારીઓને ઝડપથી સમસ્યાઓ હલ કરવાની મંજૂરી આપે છે. આ એક વિરોધાભાસ છે, પરંતુ આનાથી ઘણી વાર એડમિન્સને મદદ મળી. હું ખાતરીપૂર્વક કહીશ નહીં, પરંતુ મને લાગે છે કે એડમિન્સ પ્રોજેક્ટ કેવી રીતે કાર્ય કરે છે અને તે કેવી રીતે લખાય છે તે વધુ સમજવા લાગ્યા છે. કેટલીકવાર અમે એકબીજા સાથે કેટલીક વિગતો પણ શેર કરી હતી. સરેરાશ પ્રકાશન સમય ઘટાડીને એક કલાક કરવામાં આવ્યો છે. કેટલીકવાર અમે 30-40 મિનિટમાં પૂર્ણ થઈ જતા હતા. ભૂલોની સંખ્યામાં નોંધપાત્ર ઘટાડો થયો છે, જો દસ ગણો નહીં. અલબત્ત, અન્ય પરિબળો પણ પ્રકાશન સમયના ઘટાડા પર અસર કરે છે, જેમ કે ઑટોટેસ્ટ. દરેક પ્રકાશન પછી, અમે પૂર્વદર્શન કરવાનું શરૂ કર્યું. જેથી આખી ટીમને નવું શું છે, શું બદલાયું છે અને શું દૂર કરવામાં આવ્યું છે તેનો ખ્યાલ આવે. કમનસીબે, એડમિન હંમેશા તેમની પાસે આવતા નથી, સારું, એડમિન વ્યસ્ત છે... ડેવલપર તરીકે મારી નોકરીનો સંતોષ નિઃશંકપણે વધ્યો છે. જ્યારે તમે તમારી યોગ્યતાના ક્ષેત્રમાં હોય તેવી લગભગ કોઈપણ સમસ્યાને ઝડપથી ઉકેલી શકો છો, ત્યારે તમે ટોચ પર અનુભવો છો. પછીથી, હું સમજીશ કે અમુક અંશે અમે એક devops સંસ્કૃતિ રજૂ કરી છે, અલબત્ત, સંપૂર્ણપણે નહીં, પરંતુ પરિવર્તનની શરૂઆત પણ પ્રભાવશાળી હતી.

વાર્તા ત્રણ
શરુઆત. એક એડમિન, નાના વિકાસ વિભાગ. આગમન પર હું સંપૂર્ણ શૂન્ય છું, કારણ કે... મેઇલ સિવાય મારી પાસે ક્યાંય ઍક્સેસ નથી. અમે એડમિનને લખીએ છીએ અને ઍક્સેસ માટે પૂછીએ છીએ. વધુમાં, એવી માહિતી છે કે તે નવા કર્મચારી અને લોગિન/પાસવર્ડ જારી કરવાની જરૂરિયાત વિશે વાકેફ છે. તેઓ રીપોઝીટરી અને VPN માંથી ઍક્સેસ આપે છે. વિકિ, ટીમસિટી, રનડેસ્કની ઍક્સેસ શા માટે આપવી? એક વ્યક્તિ માટે નકામી વસ્તુઓ કે જેને સમગ્ર બેકએન્ડ ભાગ લખવા માટે બોલાવવામાં આવ્યો હતો. માત્ર સમય જતાં આપણે કેટલાક સાધનોની ઍક્સેસ મેળવીએ છીએ. આગમન, અલબત્ત, અવિશ્વાસ સાથે મળ્યા હતા. હું ધીમે ધીમે પ્રોજેક્ટનું ઇન્ફ્રાસ્ટ્રક્ચર ચેટ્સ અને અગ્રણી પ્રશ્નો દ્વારા કેવી રીતે કાર્ય કરે છે તેની અનુભૂતિ કરવાનો પ્રયાસ કરી રહ્યો છું. મૂળભૂત રીતે હું કંઈપણ ઓળખતો નથી. ઉત્પાદન પહેલા જેવું જ બ્લેક બોક્સ છે. પરંતુ તેનાથી પણ વધુ, પરીક્ષણ માટે ઉપયોગમાં લેવાતા સ્ટેજ સર્વર પણ બ્લેક બોક્સ છે. અમે ત્યાં ગિટમાંથી શાખા જમાવવા સિવાય બીજું કંઈ કરી શકતા નથી. અમે અમારી એપ્લિકેશનને .env ફાઇલોની જેમ ગોઠવી શકતા નથી. આવી કામગીરી માટે પ્રવેશ આપવામાં આવતો નથી. ટેસ્ટ સર્વર પર તમારી એપ્લિકેશનની રૂપરેખામાં લાઇન બદલવા માટે તમારે ભીખ માંગવી પડશે. (એક સિદ્ધાંત છે કે પ્રબંધકો માટે પ્રોજેક્ટ પર પોતાને મહત્વપૂર્ણ લાગે તે મહત્વપૂર્ણ છે; જો તેઓને રૂપરેખામાં લીટીઓ બદલવા માટે કહેવામાં ન આવે, તો તેમની જરૂર રહેશે નહીં). સારું, હંમેશની જેમ, તે અનુકૂળ નથી? આ ઝડપથી કંટાળાજનક બની જાય છે, એડમિન સાથેની સીધી વાતચીત પછી અમને જાણવા મળ્યું કે ડેવલપર્સનો જન્મ ખરાબ કોડ લખવા માટે થયો હતો, તેઓ સ્વભાવે અસમર્થ વ્યક્તિઓ છે અને તેમને ઉત્પાદનથી દૂર રાખવું વધુ સારું છે. પરંતુ અહીં પણ ટેસ્ટ સર્વર્સમાંથી, માત્ર કિસ્સામાં. સંઘર્ષ ઝડપથી વધી રહ્યો છે. એડમિન સાથે કોઈ વાતચીત નથી. તે એકલા હોવાના કારણે પરિસ્થિતિ વધુ વણસી છે. નીચેનું એક લાક્ષણિક ચિત્ર છે. પ્રકાશન. ચોક્કસ કાર્યક્ષમતા કામ કરતી નથી. શું ચાલી રહ્યું છે તે સમજવામાં અમને લાંબો સમય લાગે છે, વિકાસકર્તાઓના વિવિધ વિચારો ચેટમાં નાખવામાં આવે છે, પરંતુ આવી પરિસ્થિતિમાં એડમિન સામાન્ય રીતે માની લે છે કે વિકાસકર્તાઓ દોષિત છે. પછી તે ચેટમાં લખે છે, રાહ જુઓ, મેં તેને સુધાર્યો. જ્યારે સમસ્યા શું છે તે વિશેની માહિતી સાથે વાર્તા છોડી દેવાનું કહેવામાં આવે છે, ત્યારે અમને ઝેરી બહાનું મળે છે. જેમ કે, જ્યાં તે સંબંધિત નથી ત્યાં તમારા નાકને ચોંટાડો નહીં. વિકાસકર્તાઓએ કોડ લખવો આવશ્યક છે. જ્યારે પ્રોજેક્ટમાં શરીરની ઘણી હિલચાલ એક જ વ્યક્તિમાંથી પસાર થાય છે અને દરેકને જરૂરી ઑપરેશન્સ કરવા માટે ફક્ત તેની પાસે જ ઍક્સેસ હોય છે તે પરિસ્થિતિ અત્યંત દુઃખદ છે. આવી વ્યક્તિ એક ભયંકર અવરોધ છે. જો Devops વિચારો સમય-ટુ-માર્કેટ ઘટાડવાનો પ્રયત્ન કરે છે, તો આવા લોકો Devops વિચારોના સૌથી ખરાબ દુશ્મન છે. કમનસીબે, પડદો અહીં બંધ થાય છે.

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

સ્ત્રોત: www.habr.com