අද, Bitrix24 සේවාවට ගිගාබිට් සිය ගණනක් ගමනාගමනය නොමැත, නැතහොත් විශාල සේවාදායක සමූහයක් නොමැත (නමුත්, ඇත්ත වශයෙන්ම, පවතින ඒවා කිහිපයක් තිබේ). නමුත් බොහෝ ගනුදෙනුකරුවන් සඳහා එය සමාගම තුළ වැඩ කිරීම සඳහා ප්රධාන මෙවලම වේ; එය සැබෑ ව්යාපාර-විවේචනාත්මක යෙදුමකි. ඒ නිසා වැටෙන්න විදිහක් නෑ. බිඳවැටීම සිදුවුවහොත්, නමුත් කිසිවෙකු කිසිවක් නොදැක්කා සේ සේවාව ඉතා ඉක්මනින් "ප්‍රකෘතිමත්" වූයේ නම් කුමක් කළ යුතුද? කාර්යයේ ගුණාත්මකභාවය සහ සේවාදායකයින්ගේ සංඛ්‍යාව අහිමි නොවී අසාර්ථකත්වය ක්රියාත්මක කළ හැක්කේ කෙසේද? Bitrix24 හි වලාකුළු සේවා අධ්‍යක්ෂ ඇලෙක්සැන්ඩර් ඩෙමිඩොව්, නිෂ්පාදනයේ පැවැත්මේ වසර 7 තුළ වෙන් කිරීමේ ක්රමය පරිණාමය වී ඇති ආකාරය ගැන අපගේ බ්ලොග් අඩවිය සඳහා කතා කළේය.
“අපි මීට වසර 24කට පෙර SaaS ලෙස Bitrix7 දියත් කළා. ප්රධාන දුෂ්කරතාවය බොහෝ විට පහත සඳහන් විය හැකිය: එය SaaS ලෙස ප්‍රසිද්ධියේ දියත් කිරීමට පෙර, මෙම නිෂ්පාදනය හුදෙක් පෙට්ටි විසඳුමක ආකෘතියෙන් පැවතුනි. සේවාදායකයින් එය අපෙන් මිල දී ගෙන, ඔවුන්ගේ සේවාදායකයන් මත සත්කාරකත්වය ලබා දී, ආයතනික ද්වාරයක් පිහිටුවා - සේවක සන්නිවේදනය, ගොනු ගබඩා කිරීම, කාර්ය කළමනාකරණය, CRM සඳහා පොදු විසඳුමක්, එපමණයි. 2012 වන විට, අපි එය SaaS ලෙස දියත් කිරීමට අවශ්‍ය බව තීරණය කළෙමු, එය අප විසින්ම පරිපාලනය කරමින්, වැරදි ඉවසීම සහ විශ්වසනීයත්වය සහතික කළෙමු. අපි අතරමගදී අත්දැකීම් ලබා ගත්තෙමු, මන්ද එතෙක් අපට එය නොතිබූ බැවිනි - අපි මෘදුකාංග නිෂ්පාදකයින් පමණි, සේවා සපයන්නන් නොවේ.
සේවාව දියත් කිරීමේදී, වඩාත්ම වැදගත් දෙය වන්නේ වැරදි ඉවසීම, විශ්වසනීයත්වය සහ සේවාවේ නිරන්තර ලබා ගැනීම සහතික කිරීම බව අපි තේරුම් ගත්තෙමු, මන්ද ඔබට සරල සාමාන්‍ය වෙබ් අඩවියක් තිබේ නම්, වෙළඳසැලක්, උදාහරණයක් ලෙස, එය ඔබ මතට වැටී එහි වාඩි වී සිටී. පැයක්, ඔබ පමණක් දුක් විඳිනවා, ඔබට ඇණවුම් අහිමි වේ, ඔබට ගනුදෙනුකරුවන් අහිමි වේ, නමුත් ඔබේ සේවාදායකයා සඳහාම, මෙය ඔහුට ඉතා තීරණාත්මක නොවේ. ඇත්ත වශයෙන්ම, ඔහු කලබල විය, නමුත් ඔහු ගොස් වෙනත් වෙබ් අඩවියකින් එය මිලදී ගත්තේය. මෙය සමාගම තුළ ඇති සියලුම වැඩ, සන්නිවේදනයන්, තීරණ බැඳී ඇති යෙදුමක් නම්, වඩාත්ම වැදගත් දෙය නම් පරිශීලකයින්ගේ විශ්වාසය දිනා ගැනීමයි, එනම් ඔවුන්ව පහත් නොකිරීමට සහ වැටීමට ඉඩ නොදීම. ඇතුළත යමක් ක්රියා නොකරන්නේ නම් සියලු වැඩ නතර කළ හැකි බැවිනි.
Bitrix.24 SaaS ලෙස
අපි පළමු මූලාකෘතිය මහජන දියත් කිරීමට වසරකට පෙර 2011 දී එකලස් කළෙමු. අපි එය සතියකින් පමණ එකලස් කර, එය දෙස බැලුවෙමු, එය කරකවන්නෙමු - එය පවා ක්රියාත්මක විය. එනම්, ඔබට පෝරමයට ගොස් එහි ද්වාරයෙහි නම ඇතුළත් කළ හැකිය, නව ද්වාරයක් විවෘත වනු ඇත, සහ පරිශීලක පදනමක් නිර්මාණය වනු ඇත. අපි එය දෙස බලා, නිෂ්පාදිතය ප්‍රතිපත්තිමය වශයෙන් තක්සේරු කර, එය ඉවත් කර, වසරක් පුරා එය පිරිපහදු කළෙමු. අපට විශාල කාර්යයක් තිබූ නිසා: අපට විවිධ කේත පදනම් දෙකක් සෑදීමට අවශ්‍ය නොවීය, වෙනම ඇසුරුම් කළ නිෂ්පාදනයක්, වෙනම වලාකුළු විසඳුම් සඳහා සහය දැක්වීමට අපට අවශ්‍ය නොවීය - අපට ඒ සියල්ල එක් කේතයක් තුළ කිරීමට අවශ්‍ය විය.
එකල සාමාන්‍ය වෙබ් යෙදුමක් වූයේ PHP කේතයක් ක්රියාත්මක වන එක් සේවාදායකයක්, mysql දත්ත සමුදායක්, ගොනු උඩුගත කිරීම, ලේඛන, පින්තූර උඩුගත කිරීමේ ෆෝල්ඩරයට දමනු ලැබේ - හොඳයි, ඒ සියල්ල ක්රියාත්මක වේ. අහෝ, මෙය භාවිතයෙන් විවේචනාත්මක ස්ථාවර වෙබ් සේවාවක් දියත් කළ නොහැක. එහිදී, බෙදා හරින ලද හැඹිලියට සහය නොදක්වයි, දත්ත සමුදා අනුවර්තනය සඳහා සහය නොදක්වයි.
අපි අවශ්‍යතා සකස් කළෙමු: මෙය විවිධ ස්ථානවල ස්ථානගත වීමේ හැකියාව, අනුවර්තනයට සහාය වීම සහ විවිධ භූගෝලීය වශයෙන් බෙදා හරින ලද දත්ත මධ්‍යස්ථානවල ඉතා මැනවින් පිහිටා තිබීමයි. නිෂ්පාදන තර්කනය සහ ඇත්ත වශයෙන්ම දත්ත ගබඩා කිරීම වෙන් කරන්න. බර අනුව ගතිකව පරිමාණය කිරීමට සහ ස්ථිතික සම්පූර්ණයෙන්ම ඉවසා සිටීමට හැකි වන්න. මෙම සලකා බැලීම් වලින්, ඇත්ත වශයෙන්ම, නිෂ්පාදිතය සඳහා වන අවශ්‍යතා මතු වූ අතර, එය වසර පුරා අපි පිරිපහදු කළෙමු. මෙම කාලය තුළ, ඒකාබද්ධ වූ වේදිකාවේ - පෙට්ටි විසඳුම් සඳහා, අපගේම සේවය සඳහා - අපි අපට අවශ්‍ය දේවල් සඳහා සහාය ලබා දුන්නෙමු. නිෂ්පාදනයේ මට්ටමින් mysql අනුවර්තනය සඳහා සහාය: එනම්, කේතය ලියන සංවර්ධකයා ඔහුගේ ඉල්ලීම් බෙදා හරින ආකාරය ගැන සිතන්නේ නැත, ඔහු අපගේ api භාවිතා කරයි, සහ ස්වාමිවරුන් අතර ලිවීමේ සහ කියවීමේ ඉල්ලීම් නිවැරදිව බෙදා හරින ආකාරය අපි දනිමු. සහ වහලුන්.
අපි විවිධ ක්ලවුඩ් වස්තු ගබඩා සඳහා නිෂ්පාදන මට්ටමින් සහාය ලබා දී ඇත: google ගබඩාව, amazon s3, සහ open stack swift සඳහා සහය. එබැවින්, සේවාවක් ලෙස අපට සහ ඇසුරුම් කළ විසඳුමක් සමඟ වැඩ කරන සංවර්ධකයින්ට මෙය පහසු විය: ඔවුන් අපගේ API වැඩ සඳහා භාවිතා කරන්නේ නම්, ගොනුව අවසානයේ දේශීයව ගොනු පද්ධතියේ හෝ සුරැකෙන්නේ කොතැනදැයි ඔවුන් සිතන්නේ නැත. වස්තුව ගොනු ගබඩාව තුළ .
එහි ප්රතිඵලයක් වශයෙන්, අපි සම්පූර්ණ දත්ත මධ්යස්ථානයේ මට්ටමින් වෙන් කර ගැනීමට වහාම තීරණය කළෙමු. 2012 දී, අපි සම්පූර්ණයෙන්ම Amazon AWS මත දියත් කළේ අපට දැනටමත් මෙම වේදිකාව සමඟ අත්දැකීම් ඇති බැවිනි - අපගේම වෙබ් අඩවිය එහි සත්කාරකත්වය ලබා දී ඇත. සෑම කලාපයකම Amazon හට ලබා ගත හැකි කලාප කිහිපයක් තිබීම අප ආකර්ෂණය විය - ඇත්ත වශයෙන්ම, (ඔවුන්ගේ පාරිභාෂිතය තුළ) එකිනෙකින් අඩු හෝ වැඩි වශයෙන් ස්වාධීන වන සහ සම්පූර්ණ දත්ත මධ්‍යස්ථානයක මට්ටමින් අපට වෙන් කරවා ගැනීමට ඉඩ සලසන දත්ත මධ්‍යස්ථාන කිහිපයක්: එය හදිසියේ අසාර්ථක වුවහොත්, දත්ත සමුදායන් master-master ලෙස අනුකරණය කරනු ලැබේ, වෙබ් යෙදුම් සේවාදායකයන් උපස්ථ කරනු ලැබේ, සහ ස්ථිතික දත්ත s3 වස්තු ගබඩාව වෙත ගෙන යනු ලැබේ. භාරය සමතුලිත වේ - එම අවස්ථාවේ ඇමේසන් එල්බ් විසින්, නමුත් ටික වේලාවකට පසුව අපි අපගේම බර සමතුලිතයන් වෙත පැමිණියෙමු, මන්ද අපට වඩාත් සංකීර්ණ තර්කනයක් අවශ්‍ය වූ බැවිනි.
ඔවුන්ට අවශ්‍ය වූයේ ඔවුන්ට ලැබුණු දෙයයි...
අපට සහතික කිරීමට අවශ්‍ය සියලුම මූලික දේවල් - සේවාදායකයන්ගේ වැරදි ඉවසීම, වෙබ් යෙදුම්, දත්ත සමුදායන් - සියල්ල හොඳින් ක්රියාත්මක විය. සරලම අවස්ථාව: අපගේ වෙබ් යෙදුම් වලින් එකක් අසමත් වුවහොත්, සියල්ල සරලයි - ඒවා සමතුලිතතාවයෙන් ඉවත් කර ඇත.
සමතුලිතය (එවකට එය ඇමේසන්ගේ එල්බ්) ක්රියා විරහිත යන්ත්‍ර සෞඛ්‍යයට අහිතකර ලෙස සලකුණු කර ඒවායේ බර බෙදා හැරීම අක්රිය කළේය. ඇමේසන් ස්වයංක්‍රීය පරිමාණය ක්රියාත්මක විය: බර වැඩි වූ විට, ස්වයංක්‍රීය පරිමාණය කිරීමේ කණ්ඩායමට නව යන්ත්‍ර එකතු කරන ලදී, බර නව යන්ත්‍රවලට බෙදා හරින ලදි - සියල්ල හොඳින් විය. අපගේ සමතුලිතයන් සමඟ, තර්කනය ආසන්න වශයෙන් සමාන වේ: යෙදුම් සේවාදායකයට යමක් සිදුවුවහොත්, අපි එයින් ඉල්ලීම් ඉවත් කර, මෙම යන්ත්‍ර ඉවතට විසි කරන්න, නව ඒවා ආරම්භ කර දිගටම වැඩ කරන්නෙමු. මෙම යෝජනා ක්රමය වසර ගණනාවක් තිස්සේ ටිකක් වෙනස් වී ඇත, නමුත් දිගටම වැඩ කරයි: එය සරල, තේරුම් ගත හැකි අතර, එය සමඟ දුෂ්කරතා නොමැත.
අපි ලොව පුරා වැඩ කරන්නෙමු, පාරිභෝගික පැටවීම් උපරිමයෙන් සම්පූර්ණයෙන්ම වෙනස් වන අතර, සුහදශීලී ආකාරයකින්, අපගේ පද්ධතියේ ඕනෑම අංගයක් මත ඕනෑම වේලාවක - පාරිභෝගිකයින්ගේ අවධානයට ලක් නොවන පරිදි යම් සේවා කටයුතු සිදු කිරීමට අපට හැකි විය යුතුය. එබැවින්, දෙවන දත්ත මධ්යස්ථානය වෙත භාරය නැවත බෙදාහැරීම, මෙහෙයුම් වලින් දත්ත සමුදාය අක්රිය කිරීමට අපට අවස්ථාව තිබේ.
ඒ සියල්ල ක්රියාත්මක වන්නේ කෙසේද? — අපි ක්‍රියාකාරී දත්ත මධ්‍යස්ථානයකට ගමනාගමනය මාරු කරමු - දත්ත මධ්යස්ථානයේ අනතුරක් සිදුවුවහොත්, සම්පූර්ණයෙන්ම, මෙය එක් දත්ත ගබඩාවක් සමඟ අපගේ සැලසුම් සහගත කාර්යයක් නම්, අපි මෙම ගනුදෙනුකරුවන්ට සේවය කරන ගමනාගමනයෙන් කොටසක් දෙවන දත්ත මධ්‍යස්ථානයකට මාරු කරමු, අත්හිටුවීම එය අනුකරණය. දෙවන දත්ත මධ්යස්ථානයේ බර වැඩි වී ඇති නිසා වෙබ් යෙදුම් සඳහා නව යන්ත්‍ර අවශ්‍ය නම්, ඒවා ස්වයංක්‍රීයව ආරම්භ වේ. අපි වැඩ අවසන් කර, අනුකරණය යථා තත්ත්වයට පත් කර, අපි සම්පූර්ණ බර ආපසු ලබා දෙන්නෙමු. අපට දෙවන DC හි යම් කාර්යයක් පිළිබිඹු කිරීමට අවශ්‍ය නම්, උදාහරණයක් ලෙස, පද්ධති යාවත්කාලීන කිරීම් ස්ථාපනය කිරීම හෝ දෙවන දත්ත සමුදායේ සැකසුම් වෙනස් කිරීම, පසුව, සාමාන්‍යයෙන්, අපි අනෙක් දිශාවට එකම දේ නැවත කරන්නෙමු. මෙය හදිසි අනතුරක් නම්, අපි සෑම දෙයක්ම සුළු වශයෙන් කරන්නෙමු: අපි නිරීක්ෂණ පද්ධතියේ සිදුවීම් හසුරුවන්න යාන්ත්‍රණය භාවිතා කරමු. චෙක්පත් කිහිපයක් ක්රියා විරහිත කර තත්ත්වය තීරණාත්මක වන විට, අපි මෙම හෝ එම තර්කනය ක්රියාත්මක කළ හැකි හසුරුවන්නක් වන මෙම හසුරුවන්නා ධාවනය කරන්නෙමු. එක් එක් දත්ත සමුදාය සඳහා, අපි එය අසාර්ථක වන්නේ කුමන සේවාදායකයද යන්න සහ එය නොමැති නම් ගමනාගමනය මාරු කළ යුතු ස්ථානය සඳහන් කරමු. ඓතිහාසික වශයෙන්, අපි nagios හෝ එහි සමහර ගෑරුප්පු එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් භාවිතා කරමු. ප්‍රතිපත්තිමය වශයෙන්, ඕනෑම අධීක්ෂණ පද්ධතියක පාහේ සමාන යාන්ත්‍රණ පවතී; අපි තවම වඩා සංකීර්ණ කිසිවක් භාවිතා නොකරමු, නමුත් සමහර විට අපි යම් දිනක භාවිතා කරනු ඇත. දැන් අධීක්ෂණය නොපැවතීම නිසා ක්රියාත්මක වන අතර යමක් මාරු කිරීමේ හැකියාව ඇත.
අපි සියල්ල වෙන් කර තිබේද?
අපට ඇමරිකා එක්සත් ජනපදයෙන් බොහෝ සේවාදායකයින්, යුරෝපයෙන් බොහෝ සේවාදායකයින්, නැගෙනහිරට සමීප බොහෝ සේවාදායකයින් - ජපානය, සිංගප්පූරුව සහ යනාදිය ඇත. ඇත්ත වශයෙන්ම, ගනුදෙනුකරුවන්ගෙන් විශාල කොටසක් රුසියාවේ සිටිති. එනම්, වැඩ එක් කලාපයක නොවේ. පරිශීලකයින්ට ඉක්මන් ප්‍රතිචාරයක් අවශ්‍ය වේ, විවිධ දේශීය නීතිවලට අනුකූල වීමේ අවශ්‍යතා ඇත, සෑම කලාපයකම අපි දත්ත මධ්‍යස්ථාන දෙකක් වෙන් කර ගනිමු, තවද අමතර සේවාවන් කිහිපයක් ඇත, ඒවා නැවතත් එක් කලාපයක් තුළ තැබීමට පහසු වේ - සිටින සේවාදායකයින් සඳහා මෙම කලාපය වැඩ කරයි. REST හසුරුවන්නන්, අවසර සේවාදායක, ඒවා සමස්තයක් ලෙස සේවාලාභියාගේ ක්‍රියාකාරිත්වය සඳහා අඩු තීරණාත්මක වේ, ඔබට කුඩා පිළිගත හැකි ප්‍රමාදයකින් ඒවා හරහා මාරු කළ හැකිය, නමුත් ඒවා නිරීක්ෂණය කරන්නේ කෙසේද සහ කුමක් කළ යුතුද යන්න පිළිබඳ රෝදය නැවත සොයා ගැනීමට ඔබට අවශ්‍ය නැත. ඔවුන් සමග. එමනිසා, අපි අතිරේක නිෂ්පාදනවල යම් ආකාරයක නිපුණතාවයක් වර්ධනය කරනවාට වඩා පවතින විසඳුම් උපරිම ලෙස භාවිතා කිරීමට උත්සාහ කරමු. සහ කොහේ හරි අපි සුළු වශයෙන් DNS මට්ටමින් මාරු කිරීම භාවිතා කරන අතර, අපි එම DNS මගින් සේවාවේ සජීවී බව තීරණය කරමු. Amazon සතුව මාර්ග 53 සේවාවක් ඇත, නමුත් එය ඔබට ඇතුළත් කළ හැකි DNS එකක් පමණක් නොවේ, එය එයයි - එය වඩාත් නම්‍යශීලී සහ පහසු වේ. එය හරහා ඔබට භූ ස්ථානගත කිරීම් සමඟ භූ-බෙදාහැරි සේවාවන් ගොඩනගා ගත හැකිය, ඔබ සේවාදායකයා පැමිණියේ කොහෙන්ද යන්න තීරණය කිරීමට සහ ඔහුට යම් වාර්තා ලබා දීමට එය භාවිතා කරන විට - එහි ආධාරයෙන් ඔබට අසාර්ථක ගෘහ නිර්මාණ ශිල්පය ගොඩනගා ගත හැකිය. එම සෞඛ්‍ය පරීක්ෂාවන් මාර්ග අංක 53 තුළම වින්‍යාස කර ඇත, ඔබ නිරීක්ෂණය කරන අන්ත ලක්ෂ්‍ය සකසන්න, ප්‍රමිතික සකසන්න, සේවාවේ “සජීවී බව” තීරණය කිරීමට කුමන ප්‍රොටෝකෝල සකසන්න - tcp, http, https; සේවාව ජීවමානද නැද්ද යන්න තීරණය කරන චෙක්පත් වාර ගණන සකසන්න. ඩීඑන්එස් තුළම ඔබ ප්‍රාථමික වන්නේ කුමක්ද, ද්විතියික වන්නේ කුමක්ද, සෞඛ්‍ය පරීක්ෂාව මාර්ග 53 තුළ ක්රියාත්මක වන්නේ නම් මාරු කළ යුත්තේ කොතැනද යන්න සඳහන් කරයි. මේ සියල්ල වෙනත් මෙවලම් සමඟ කළ හැකිය, නමුත් එය පහසු වන්නේ ඇයි - අපි එය සකස් කරමු. එක් වරක් ඉහළ ගොස් පසුව අපි චෙක්පත් කරන්නේ කෙසේද, අපි මාරු කරන්නේ කෙසේද යන්න ගැන කිසිසේත් නොසිතන්න: සියල්ල තනිවම ක්රියා කරයි.
පළමු "නමුත්": 53 මාර්ගයම වෙන් කර ගන්නේ කෙසේද සහ කුමක් සමඟද? කවුද දන්නේ, එයාට මොනවා හරි උනොත්? වාසනාවකට මෙන්, අපි කිසි විටෙකත් මෙම පෝරුවට නොපැමිණි නමුත්, අපි තවමත් වෙන් කරවා ගැනීමට අවශ්‍ය යැයි අප සිතුවේ ඇයිද යන්න පිළිබඳ කතාවක් මට ඉදිරියෙන් ඇත. මෙන්න අපි කල්තියා අපටම පිදුරු තැබුවෙමු. දිනකට කිහිප වතාවක් අපි මාර්ග අංක 53 හි ඇති සියලුම කලාප සම්පූර්ණයෙන්ම බෑම කරන්නෙමු. Amazon හි API ඔබට පහසුවෙන් JSON වෙත යැවීමට ඉඩ සලසයි, අපි එය පරිවර්තනය කරන, වින්‍යාස ආකාරයෙන් උඩුගත කරන සහ දළ වශයෙන්, උපස්ථ වින්‍යාසයක් ඇති උපස්ථ සේවාදායකයන් කිහිපයක් අප සතුව ඇත. යම් දෙයක් සිදු වුවහොත්, අපට එය ඉක්මනින් DNS සැකසුම් දත්ත අහිමි නොවී අතින් යෙදවිය හැක.
දෙවන "නමුත්": මේ පින්තූරයේ තවමත් වෙන් කර නොමැති දේ කුමක්ද? සමතුලිතය ම! කලාපය අනුව අපගේ ගනුදෙනුකරුවන් බෙදා හැරීම ඉතා සරල කර ඇත. අපි සතුව bitrix24.ru, bitrix24.com, .de වසම් ඇත - දැන් විවිධ කලාපවල ක්රියාත්මක වන විවිධ ඒවා 13 ක් ඇත. අපි පහත සඳහන් දේ වෙත පැමිණියෙමු: සෑම කලාපයකටම තමන්ගේම ශේෂයන් ඇත. ජාලයේ උපරිම බර ඇති ස්ථානය අනුව මෙය කලාප හරහා බෙදා හැරීම වඩාත් පහසු කරයි. මෙය තනි සමතුලිතයක මට්ටමින් අසාර්ථක වුවහොත්, එය සරලව සේවයෙන් ඉවත් කර dns වෙතින් ඉවත් කරනු ලැබේ. සමතුලිත කණ්ඩායමක් සමඟ කිසියම් ගැටළුවක් ඇත්නම්, ඒවා වෙනත් අඩවි වල උපස්ථ කර ඒවා අතර මාරුවීම එකම මාර්ගය53 භාවිතා කරමින් සිදු කෙරේ, මන්ද කෙටි TTL නිසා මාරුවීම උපරිම මිනිත්තු 2, 3, 5 ක් ඇතුළත සිදු වේ. .
තෙවන "නමුත්": තවම වෙන් කර නැති දේ කුමක්ද? S3, නිවැරදි. අපි පරිශීලකයින් සඳහා ගබඩා කරන ලිපිගොනු s3 හි තැබූ විට, එය සන්නාහ විදීමක් බව අපි අවංකවම විශ්වාස කළ අතර එහි කිසිවක් වෙන් කිරීමට අවශ්‍ය නොවීය. නමුත් ඉතිහාසය පෙන්වන්නේ දේවල් වෙනස් ලෙස සිදු වන බවයි. සාමාන්‍යයෙන්, Amazon S3 මූලික සේවාවක් ලෙස විස්තර කරයි, මන්ද Amazon විසින්ම යන්ත්‍ර රූප, configs, AMI පින්තූර, ස්නැප්ෂොට් ගබඩා කිරීමට S3 භාවිතා කරයි ... තවද s3 බිඳ වැටුණහොත්, මෙම වසර 7 තුළ වරක් සිදු වූ පරිදි, අප භාවිතා කරන තාක් කල්. bitrix24, එය විදුලි පංකාවක් මෙන් එය අනුගමනය කරයි - අථත්‍ය යන්ත්‍ර ආරම්භ කිරීමට නොහැකි වීම, api අසාර්ථක වීම යනාදිය බොහෝ දේ ඇත.
S3 වැටෙන්න පුළුවන් - එය වරක් සිදු විය. එමනිසා, අපි පහත යෝජනා ක්රමයට පැමිණියෙමු: මීට වසර කිහිපයකට පෙර රුසියාවේ බරපතල පොදු වස්තු ගබඩා පහසුකම් නොතිබූ අතර, අපගේම දෙයක් කිරීමේ විකල්පය අපි සලකා බැලුවෙමු ... වාසනාවකට මෙන්, අපි මෙය කිරීමට පටන් ගත්තේ නැත, මන්ද අප සතුව නැති විශේෂඥ දැනුම හාරා ඇති අතර, සමහරවිට අවුල් විය හැක. දැන් Mail.ru සතුව s3-අනුකූල ආචයනය ඇත, Yandex සතුව එය ඇත, සහ වෙනත් සැපයුම්කරුවන් ගණනාවකට එය තිබේ. අපි අවසානයේ අදහසට පැමිණියෙමු, පළමුව, උපස්ථ කිරීම සහ දෙවනුව, දේශීය පිටපත් සමඟ වැඩ කිරීමේ හැකියාව අපට තිබිය යුතුය. රුසියානු කලාපය සඳහා, අපි Mail.ru Hotbox සේවාව භාවිතා කරමු, එය API s3 සමඟ අනුකූල වේ. අපට යෙදුම තුළ ඇති කේතයට කිසිදු ප්රධාන වෙනස් කිරීමක් අවශ්‍ය නොවූ අතර අපි පහත යාන්ත්‍රණය සෑදුවෙමු: s3 හි වස්තු සෑදීම/මකාදැමීම අවුලුවාලන ප්‍රේරක ඇත, Amazon සතුව Lambda නම් සේවාවක් ඇත - මෙය සේවාදායක රහිත කේතයක් දියත් කිරීමකි. සමහර ප්‍රේරක ක්‍රියාරම්භ කරන විට එය ක්රියාත්මක වේ.
අපි එය ඉතා සරලව කළෙමු: අපගේ ගිනි අවුලුවා නම්, අපි Mail.ru ගබඩාවට වස්තුව පිටපත් කරන කේතය ක්රියාත්මක කරමු. දත්තවල දේශීය පිටපත් සමඟ වැඩ සම්පූර්ණයෙන්ම දියත් කිරීම සඳහා, අපට ප්‍රතිලෝම සමමුහුර්තකරණය ද අවශ්‍ය වන අතර එමඟින් රුසියානු කොටසේ සිටින සේවාදායකයින්ට ඔවුන්ට සමීප ගබඩා සමඟ වැඩ කළ හැකිය. තැපෑල එහි ගබඩාවේ ප්‍රේරක සම්පූර්ණ කිරීමට ආසන්නයි - යටිතල පහසුකම් මට්ටමින් ප්‍රතිලෝම සමමුහුර්තකරණය සිදු කිරීමට හැකි වනු ඇත, නමුත් දැනට අපි මෙය කරන්නේ අපගේම කේතයේ මට්ටමින් ය. සේවාදායකයෙක් ගොනුවක් පළ කර ඇති බව අපි දුටුවහොත්, කේත මට්ටමේදී අපි සිදුවීම පෝලිමක තබමු, එය සැකසීමට සහ ප්‍රතිලෝම අනුකරණය කරන්නෙමු. එය නරක වන්නේ ඇයි: අපි අපගේ භාණ්ඩයෙන් පිටත අපගේ වස්තූන් සමඟ යම් ආකාරයක වැඩ කරන්නේ නම්, එනම්, යම් බාහිර මාර්ගයකින්, අපි එය සැලකිල්ලට නොගනිමු. එමනිසා, අපි කොතැනක සිට කේතය ක්රියාත්මක කළත්, අප වෙත පැමිණි වස්තුව අනෙක් දිශාවට පිටපත් වන පරිදි, ගබඩා මට්ටමින් ප්‍රේරක දිස්වන තෙක් අපි අවසානය දක්වා රැඳී සිටිමු.
කේත මට්ටමින්, අපි එක් එක් සේවාදායකයා සඳහා ගබඩා දෙකම ලියාපදිංචි කරමු: එකක් ප්රධාන එකක් ලෙස සලකනු ලැබේ, අනෙක උපස්ථ එකක් ලෙස සැලකේ. සෑම දෙයක්ම හොඳින් තිබේ නම්, අපි අපට සමීප ගබඩාව සමඟ වැඩ කරන්නෙමු: එනම්, ඇමේසන් හි සිටින අපගේ සේවාදායකයින්, ඔවුන් S3 සමඟ වැඩ කරන අතර රුසියාවේ වැඩ කරන අය Hotbox සමඟ වැඩ කරන්නෙමු. ධජය අවුලුවා ඇත්නම්, අසාර්ථකත්වය සම්බන්ධ කළ යුතු අතර, අපි සේවාදායකයින් වෙනත් ගබඩාවකට මාරු කරමු. අපට කලාපය අනුව ස්වාධීනව මෙම කොටුව සලකුණු කළ හැකි අතර ඒවා ඉදිරියට සහ පසුපසට මාරු කළ හැකිය. අපි මෙය තවමත් ප්‍රායෝගිකව භාවිතා කර නැත, නමුත් අපි මෙම යාන්ත්‍රණය සඳහා සපයා ඇති අතර කවදා හෝ අපට මෙම ස්විචය අවශ්‍ය වන අතර ප්‍රයෝජනවත් වනු ඇතැයි අපි සිතමු. මෙය දැනටමත් වරක් සිදුවී ඇත.
ඔහ්, සහ ඇමේසන් පලා ගියා ...
මෙම අප්රේල් රුසියාවේ ටෙලිග්රාම් අවහිර කිරීමේ ආරම්භයේ සංවත්සරය සනිටුහන් කරයි. මෙය යටතේ ඇති වඩාත්ම බලපෑමට ලක්වූ සැපයුම්කරු වන්නේ Amazon ය. තවද, අවාසනාවකට මෙන්, මුළු ලෝකයටම වැඩ කළ රුසියානු සමාගම් වඩාත් දුක් විඳිති.
සමාගම ගෝලීය නම් සහ රුසියාව ඒ සඳහා ඉතා කුඩා කොටසක් නම්, 3-5% - හොඳයි, එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින්, ඔබට ඒවා කැප කළ හැකිය.
මෙය තනිකරම රුසියානු සමාගමක් නම් - එය දේශීයව පිහිටා තිබිය යුතු බව මට විශ්වාසයි - හොඳයි, එය පරිශීලකයින්ටම පහසු වනු ඇත, සුවපහසු වන අතර අවදානම් අඩු වනු ඇත.
මෙය ගෝලීය වශයෙන් ක්රියාත්මක වන සහ රුසියාවෙන් සහ ලොව පුරා කොතැනක හෝ සිට ආසන්න වශයෙන් සමාන සේවාලාභීන් සංඛ්‍යාවක් සිටින සමාගමක් නම් කුමක් කළ යුතුද? කොටස්වල සම්බන්ධතාවය වැදගත් වන අතර, ඔවුන් එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් එකිනෙකා සමඟ වැඩ කළ යුතුය.
2018 මාර්තු මස අවසානයේදී, Roskomnadzor විසින් විශාලතම ක්‍රියාකරුවන් වෙත ලිපියක් යවමින් සඳහන් කර ඇත්තේ ඔවුන් අවහිර කිරීම සඳහා Amazon IP මිලියන කිහිපයක් අවහිර කිරීමට සැලසුම් කර ඇති බවයි... Zello messenger. මෙම එකම සැපයුම්කරුවන්ට ස්තූතියි - ඔවුන් සෑම කෙනෙකුටම ලිපිය සාර්ථකව කාන්දු කළ අතර, ඇමේසන් සමඟ සම්බන්ධතාවය බිඳ වැටිය හැකි බවට අවබෝධයක් තිබුණි. එය සිකුරාදා විය, අපි servers.ru වෙතින් අපගේ සගයන් වෙත කලබලයෙන් දිව ගියෙමු: “මිත්‍රවරුනි, අපට රුසියාවේ නොව ඇමේසන් හි නොව, උදාහරණයක් ලෙස, ඇම්ස්ටර්ඩෑම්හි කොතැනක හෝ පිහිටා ඇති සේවාදායකයන් කිහිපයක් අවශ්‍ය වේ” යැයි පවසමින්. අපට කිසිදු ආකාරයකින් බලපෑම් කළ නොහැකි සමහර අන්ත ලක්ෂ්‍ය සඳහා අවම වශයෙන් කෙසේ හෝ අපගේම VPN සහ ප්‍රොක්සි ස්ථාපනය කිරීමට හැකි වීම සඳහා, උදාහරණයක් ලෙස එකම s3 හි endponts - අපට නව සේවාවක් ඉහළ නැංවීමට සහ වෙනත් ip ලබා ගැනීමට උත්සාහ කළ නොහැක, අපි ඔබට තවමත් එහි යාමට අවශ්‍යයි. දින කිහිපයකින්, අපි මෙම සේවාදායකයන් පිහිටුවා, ඒවා ක්රියාත්මක කර, සාමාන්‍යයෙන්, අවහිර කිරීම ආරම්භ වූ මොහොත සඳහා සූදානම් විය. කලබලය සහ කලබලය දෙස බලා RKN මෙසේ පැවසීම කුතුහලයට කරුණකි: "නැහැ, අපි දැන් කිසිවක් අවහිර නොකරමු." (නමුත් මෙය හරියටම ටෙලිග්රාම් අවහිර කිරීමට පටන් ගත් මොහොත දක්වා ය.) බයිපාස් හැකියාවන් සකස් කර අවහිර කිරීම හඳුන්වා දී නොමැති බව වටහා ගත් අපි, කෙසේ වෙතත්, සමස්ත කාරණය නිරාකරණය කිරීමට පටන් ගත්තේ නැත. ඔව්, යම් අවස්ථාවක.
තවද 2019 දී, අපි තවමත් අවහිර කිරීමේ තත්වයන් තුළ ජීවත් වෙමු. මම ඊයේ රාත්‍රියේ බැලුවා: මිලියනයක් පමණ IPs දිගටම අවහිර කර ඇත. ඇත්ත වශයෙන්ම, Amazon සම්පූර්ණයෙන්ම වාගේ අවහිර කර ඇත, එහි උච්චතම අවස්ථාවේ දී එය මිලියන 20 ක් ලිපින කරා ළඟා විය... පොදුවේ ගත් කල, යථාර්ථය නම් අනුකූලතාවයක්, හොඳ අනුකූලතාවයක් නොතිබිය හැකිය. හදිසියේ. තාක්ෂණික හේතූන් මත එය නොපවතිනු ඇත - ගිනි, කැණීම්, ඒ සියල්ල. නැතහොත්, අප දැක ඇති පරිදි, සම්පූර්ණයෙන්ම තාක්ෂණික නොවේ. එමනිසා, ඔවුන්ගේම ASs සහිත විශාල සහ විශාල කෙනෙකුට මෙය වෙනත් ආකාරවලින් කළමනාකරණය කළ හැකිය - සෘජු සම්බන්ධතාවය සහ අනෙකුත් දේවල් දැනටමත් l2 මට්ටමේ ඇත. නමුත් අපගේ හෝ ඊටත් වඩා කුඩා අනුවාදයක් වැනි සරල අනුවාදයක, ඔබට වෙනත් තැනක ඉහළ නංවා ඇති සේවාදායකයන් මට්ටමින් අතිරික්තයක් තිබිය හැකිය, කලින් වින්‍යාස කර ඇති vpn, proxy, එම කොටස්වල වින්‍යාසය ඉක්මනින් ඒවාට මාරු කිරීමේ හැකියාව ඇත. එය ඔබගේ සම්බන්ධතාවය සඳහා ඉතා වැදගත් වේ. ඇමේසන් අවහිර කිරීම ආරම්භ වූ විට මෙය එක් වරකට වඩා අපට ප්‍රයෝජනවත් විය; නරකම අවස්ථාවෙහිදී, අපි ඒවා හරහා S3 ගමනාගමනයට පමණක් ඉඩ දුන්නෙමු, නමුත් ක්‍රමයෙන් මේ සියල්ල විසඳා ඇත.
වෙන්කර ගන්නේ කෙසේද ... සම්පූර්ණ සැපයුම්කරු?
මේ වන විට අපට සම්පූර්ණ ඇමේසන් පහත වැටුණහොත් අපට අවස්ථාවක් නොමැත. අපට රුසියාව සම්බන්ධයෙන් ද එවැනිම දර්ශනයක් තිබේ. රුසියාවේ, අපි එක් සැපයුම්කරුවෙකු විසින් සත්කාරකත්වය ලබා දුන් අතර, ඔහුගෙන් අපි අඩවි කිහිපයක් තෝරාගෙන ඇත. වසරකට පෙර අපි ගැටලුවකට මුහුණ දුන්නා: මේවා දත්ත මධ්‍යස්ථාන දෙකක් වුවද, දත්ත මධ්‍යස්ථාන දෙකටම තවමත් බලපාන සැපයුම්කරුගේ ජාල වින්‍යාස කිරීමේ මට්ටමින් දැනටමත් ගැටළු ඇති විය හැකිය. තවද අපි අඩවි දෙකෙහිම නොතිබිය හැකිය. ඇත්ත වශයෙන්ම එය සිදු විය. අපි ඇතුළත ගෘහ නිර්මාණ ශිල්පය නැවත සලකා බැලීම අවසන් කළා. එය එතරම් වෙනස් වී නැත, නමුත් රුසියාව සඳහා අපට දැන් වෙබ් අඩවි දෙකක් ඇත, ඒවා එකම සැපයුම්කරුවෙකුගෙන් නොව වෙනස් දෙකකින්. එකක් ෆේල් නම් අපිට අනිත් එකට මාරු වෙන්න පුළුවන්.
උපකල්පිත ලෙස, Amazon සඳහා අපි වෙනත් සැපයුම්කරුවෙකුගේ මට්ටමින් වෙන් කිරීමේ හැකියාව සලකා බලමු; සමහරවිට Google, සමහරවිට වෙන කෙනෙක් වෙන්න පුළුවන්... නමුත් මේ වන විට අපි ප්‍රායෝගිකව නිරීක්ෂණය කර ඇත්තේ Amazon හි එක් ලබා ගත හැකි කලාපයක මට්ටමේ අනතුරු ඇති අතර, සමස්ත කලාපයක මට්ටමේ අනතුරු තරමක් දුර්ලභ බවයි. එබැවින්, "Amazon is not Amazon" වෙන් කිරීමක් කළ හැකි බවට න්‍යායාත්මකව අපට අදහසක් ඇත, නමුත් ප්‍රායෝගිකව මෙය තවමත් එසේ නොවේ.
ස්වයංක්රීයකරණය ගැන වචන කිහිපයක්
ස්වයංක්රීයකරණය සැමවිටම අවශ්‍යද? මෙහිදී Dunning-Kruger ආචරණය සිහිපත් කිරීම සුදුසුය. "x" අක්ෂය මත අප ලබා ගන්නා අපගේ දැනුම සහ අත්දැකීම් වන අතර "y" අක්ෂය මත අපගේ ක්‍රියාවන් පිළිබඳ විශ්වාසය වේ. මුලදී අපි කිසිවක් නොදන්නා අතර කිසිසේත්ම විශ්වාස නැත. එවිට අපි ටිකක් දැනගෙන මෙගා-විශ්වාසවන්ත වෙමු - මෙය ඊනියා "මෝඩකමේ උච්චතම අවස්ථාව", "ඩිමෙන්ශියාව සහ ධෛර්යය" යන පින්තූරයෙන් මනාව විදහා දක්වයි. එහෙනම් අපි ටිකක් ඉගෙන ගෙන සටනට යන්න සූදානම්. එවිට අපි යම් දෙයක් දන්නා බව පෙනෙන නමුත් ඇත්ත වශයෙන්ම අපි බොහෝ දේ නොදන්නා විට, අපි සමහර මෙගා බරපතල වැරදි මතට ගොස් බලාපොරොත්තු සුන් වූ මිටියාවතක සිටිමු. එවිට, අපි අත්දැකීම් ලබා ගන්නා විට, අපි වඩාත් විශ්වාස කරමු.
ඇතැම් අනතුරු සඳහා විවිධ ස්වයංක්‍රීය ස්විචයන් පිළිබඳ අපගේ තර්කනය මෙම ප්‍රස්ථාරයෙන් ඉතා හොඳින් විස්තර කර ඇත. අපි ආරම්භ කළා - අපි කිසිවක් කරන්නේ කෙසේදැයි නොදැන සිටියෙමු, සියලුම වැඩ පාහේ අතින් සිදු විය. එවිට අපට සෑම දෙයකටම ස්වයංක්රීයකරණය අනුයුක්ත කළ හැකි බවත්, සාමකාමීව නිදා ගත හැකි බවත් අපට වැටහුණි. හදිසියේම අපි මෙගා-රේක් එකකට පා තබමු: ව්‍යාජ ධනාත්මක බවක් ඇති වන අතර, හොඳ ආකාරයකින්, අපට මෙය නොකළ යුතුව තිබූ විට අපි ගමනාගමනය ඉදිරියට සහ පසුපසට මාරු කරමු. එහි ප්රතිඵලයක් වශයෙන්, ප්‍රතිනිර්මාණය බිඳවැටීම හෝ වෙනත් දෙයක් - මෙය බලාපොරොත්තු සුන්වීමේ නිම්නයයි. එතකොට අපි හැමදේටම නුවණින් ප්‍රවේශ විය යුතුයි කියන අවබෝධයට එනවා. එනම්, ව්‍යාජ අනතුරු ඇඟවීමේ හැකියාව සඳහා ස්වයංක්රීයකරණය මත විශ්වාසය තැබීම අර්ථවත් කරයි. එහෙත්! ප්‍රතිවිපාක විනාශකාරී විය හැකි නම්, එය රාජකාරි මුරයට, රාජකාරියේ යෙදී සිටින ඉංජිනේරුවන්ට, ඇත්ත වශයෙන්ම අනතුරක් සිදුවී ඇති බවට වග බලා ගන්නා සහ අධීක්ෂණය කරන සහ අවශ්‍ය ක්‍රියාමාර්ග අතින් සිදු කරනු ඇත ...
නිගමනය
වසර 7 ක කාලය තුළ, අපි යමක් වැටුණු විට, භීතිය-භීතිය ඇති වූ කාරණයේ සිට, ගැටළු නොපවතියි, කාර්යයන් පමණක් ඇති බව වටහා ගැනීම දක්වා අපි ගියෙමු, ඒවා විසඳිය යුතුය - සහ කළ හැකිය. ඔබ සේවාවක් ගොඩනඟන විට, එය ඉහළින් බලන්න, සිදුවිය හැකි සියලු අවදානම් තක්සේරු කරන්න. ඔබ ඒවා වහාම දුටුවහොත්, අතිරික්තය කල්තියාම සහ දෝෂ-ඉවසන යටිතල පහසුකම් ගොඩනැගීමේ හැකියාව ලබා දෙන්න, මන්ද අසමත් විය හැකි සහ සේවාවේ අක්‍රියතාවයට තුඩු දිය හැකි ඕනෑම කරුණක් නියත වශයෙන්ම එසේ කරනු ඇත. යටිතල ව්‍යුහයේ සමහර අංග නියත වශයෙන්ම අසාර්ථක නොවන බව ඔබට පෙනුනද - එකම s3 මෙන්, ඔවුන්ට හැකි බව තවමත් මතක තබා ගන්න. අවම වශයෙන් න්‍යායාත්මකව, යමක් සිදුවුවහොත් ඔබ ඔවුන් සමඟ කරන්නේ කුමක්ද යන්න පිළිබඳ අදහසක් ඇත. අවදානම් කළමනාකරණ සැලැස්මක් ඇත. ඔබ සෑම දෙයක්ම ස්වයංක්‍රීයව හෝ අතින් සිදු කිරීම ගැන සිතන විට, අවදානම තක්සේරු කරන්න: ස්වයංක්රීයකරණය සියල්ල මාරු කිරීමට පටන් ගන්නේ නම් කුමක් සිදුවේද - මෙය අනතුරකට සාපේක්ෂව ඊටත් වඩා නරක තත්වයකට තුඩු නොදෙන්නේද? සමහර විට කොතැනක හෝ ස්වයංක්රීයකරණය භාවිතා කිරීම සහ රාජකාරියේ යෙදී සිටින ඉංජිනේරුවාගේ ප්‍රතික්‍රියාව අතර සාධාරණ සම්මුතියක් භාවිතා කිරීම අවශ්‍ය වේ, ඔහු සැබෑ චිත්‍රය තක්සේරු කර යමක් එම ස්ථානයේම මාරු කළ යුතුද නැතහොත් “ඔව්, නමුත් දැන් නොවේ” යන්න තේරුම් ගනී.
පරිපූර්ණත්වය සහ සැබෑ උත්සාහය, කාලය, මුදල් අතර සාධාරණ සම්මුතියක් ඔබට අවසානයේ ඇති යෝජනා ක්රමයට වියදම් කළ හැකිය.
මෙම පාඨය සමුළුවේදී ඇලෙක්සැන්ඩර් ඩෙමිඩොව්ගේ වාර්තාවේ යාවත්කාලීන සහ පුළුල් කරන ලද අනුවාදයකි .
මූලාශ්රය: www.habr.com