1C વિકાસકર્તાની વાર્તાઓ: એડમિન

તમામ 1C વિકાસકર્તાઓ એક યા બીજી રીતે IT સેવાઓ સાથે અને સીધા જ સિસ્ટમ એડમિનિસ્ટ્રેટર્સ સાથે નજીકથી સંપર્ક કરે છે. પરંતુ આ ક્રિયાપ્રતિક્રિયા હંમેશા સરળતાથી ચાલતી નથી. હું તમને આ વિશે કેટલીક રમુજી વાર્તાઓ કહેવા માંગુ છું.

હાઇ-સ્પીડ કોમ્યુનિકેશન ચેનલ

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

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

આ બધું સફળતાપૂર્વક ગોઠવવામાં આવ્યું હતું, ઓપરેશનમાં મૂકવામાં આવ્યું હતું અને સામાન્ય રીતે નિષ્ફળતા વિના કામ કર્યું હતું.

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

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

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

શાંત થાઓ, હું કહું છું. અમારી પાસે તમારું રાત્રિનું બેકઅપ છે. જવાબમાં, મૌન હતું, જેના દ્વારા મને સમજાયું કે મેં હમણાં જ એક માણસનો જીવ બચાવ્યો છે. અમે ચર્ચા કરવાનું શરૂ કરીએ છીએ કે આ નકલને નવા, નવા જમાવાયેલા સર્વરમાં કેવી રીતે સ્થાનાંતરિત કરવી. પરંતુ અહીં પણ એક સમસ્યા ઊભી થઈ.

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

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

ત્યારબાદ, IT વિભાગને અમારી બધી વિનંતીઓ ખૂબ જ ઝડપથી ઉકેલાઈ ગઈ અને કોઈ વધુ મતભેદો ઊભા થયા નહીં.

તમારા સિસ્ટમ એડમિનિસ્ટ્રેટરનો સંપર્ક કરો

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

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

પરિણામે, અમે તેને કોઈપણ સમસ્યા વિના Apache પર લોન્ચ કર્યું. IIS ક્યારેય હાર્યું ન હતું.

એક સ્તર ઊંડા

અમારી પાસે એક ક્લાયન્ટ હતો - એક નાનું ઉત્પાદન એન્ટરપ્રાઇઝ. તેમની પાસે સર્વર હતું, એક પ્રકારનું “ક્લાસિક” 3 ઇન 1: ટર્મિનલ સર્વર + એપ્લિકેશન સર્વર + ડેટાબેઝ સર્વર. તેઓએ SCP પર આધારિત કેટલાક ઉદ્યોગ ગોઠવણીમાં કામ કર્યું, ત્યાં લગભગ 15-20 વપરાશકર્તાઓ હતા, સિસ્ટમની કામગીરી, સિદ્ધાંતમાં, દરેકને અનુકૂળ હતી.

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

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

થોડા સમય પછી, એડમિન મને નવા સર્વરનું IP સરનામું અને લૉગિન ઓળખપત્રો મોકલે છે. તે કહે છે કે MS SQL અને 1C સર્વર ઘટકો ત્યાં તૈનાત છે, અને ડેટાબેઝને સ્થાનાંતરિત કરવાની જરૂર છે, પરંતુ હમણાં માટે માત્ર DBMS સર્વર પર, કારણ કે 1C કી સાથે કેટલીક સમસ્યાઓ ઊભી થઈ છે.

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

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

હમ્મ... વર્ચ્યુઅલ સર્વર? એવું લાગે છે કે ક્યારેય કોઈ વર્ચ્યુઅલાઈઝેશન થયું નથી અને ક્યારેય થયું નથી... મને વિન્ડોઝ સર્વર 1 માં હાઈપર-વી પર વર્ચ્યુઅલ મશીન પર 2008C સર્વર કીને ફોરવર્ડ કરવાની અશક્યતા સાથેની એકદમ જાણીતી સમસ્યા યાદ છે. અને અહીં મારામાં કેટલીક શંકાઓ ઉભી થવા લાગે છે...

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

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

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

ઠીક છે, અલબત્ત, તેઓ વર્ચ્યુઅલ મશીન પર સર્વર કી ફોરવર્ડ કરી શક્યા નથી. પરિણામે, બધું જ બાકી હતું: ભૌતિક મશીન પર ટર્મિનલ સર્વર + 1C ક્લસ્ટર, વર્ચ્યુઅલમાં ડેટાબેઝ સર્વર.

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

હાર્ડ ડ્રાઈવ વેકેશન શેડ્યૂલ

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

સૌ પ્રથમ, ઉત્પાદન અને પરીક્ષણ ડેટાબેસેસ જમાવવા માટે જરૂરી છે. વિકાસકર્તાએ કનેક્શન ડેટા મેળવ્યો, સર્વરમાં લોગ ઇન કર્યું, MS SQL ઇન્સ્ટોલ કરેલું, 1C સર્વર જુએ, 2 લોજિકલ ડ્રાઇવ્સ જુએ: 250 ગીગાબાઇટ્સની ક્ષમતાવાળી ડ્રાઇવ “C” અને 1 ટેરાબાઇટની ક્ષમતા સાથે “D” ડ્રાઇવ. ઠીક છે, "C" એ સિસ્ટમ છે, "D" ડેટા માટે છે, વિકાસકર્તા તાર્કિક રીતે નક્કી કરે છે અને ત્યાં તમામ ડેટાબેસેસ ગોઠવે છે. મેં બેકઅપ સહિતની જાળવણી યોજનાઓ પણ સેટ કરી છે, માત્ર કિસ્સામાં (જો કે અમે આ માટે જવાબદાર નથી). સાચું, બેકઅપ અહીં "D" માં ઉમેરવામાં આવ્યા હતા. ભવિષ્યમાં, તેને કેટલાક અલગ નેટવર્ક સંસાધનમાં પુનઃરૂપરેખાંકિત કરવાની યોજના હતી.

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

એક સોમવારની સવાર સુધી બધું બરાબર ચાલી રહ્યું હતું જ્યારે ખબર પડી કે ડેટાબેઝ ડિસ્ક ખૂટે છે. સર્વર પર ખાલી કોઈ "D" નથી અને બસ.

વધુ તપાસમાં આ બહાર આવ્યું: આ "સર્વર" વાસ્તવમાં સ્થાનિક સિસ્ટમ એડમિનિસ્ટ્રેટરનું કાર્ય કમ્પ્યુટર હતું. સાચું, તેમાં હજી પણ સર્વર ઓએસ હતું. આ વ્યવસ્થાપકની વ્યક્તિગત USB ડ્રાઇવ સર્વરમાં પ્લગ કરેલી હતી. અને તેથી એડમિનિસ્ટ્રેટર વેકેશન પર ગયા, તેમની સાથે સ્ક્રૂ લઈને, ટ્રિપ માટે તેમાં મૂવીઝ પમ્પ કરવાના ધ્યેય સાથે.

ભગવાનનો આભાર, તેણે ડેટાબેઝ ફાઇલો કાઢી નાખવાનું મેનેજ કર્યું નહીં અને ઉત્પાદક ડેટાબેઝને પુનઃસ્થાપિત કરવામાં વ્યવસ્થાપિત કર્યું.

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

પરંતુ તે એક સંપૂર્ણપણે અલગ વાર્તા છે ...

સોર્સ: www.habr.com