Процес на развитие: бързо срещу постепенно

Аспекти за използване на най-добрите практики в децентрализиран свят

През 2001 г. един от нашите разработчици на име Филип се опита да инсталира собствен софтуер на компанията на сайта на клиента. Долната линия е, че тогава базата данни на Oracle се срина, така че за да реши проблема, той трябваше да отмени няколко полета до дома и да работи няколко дни като администратор (DBA), за да го възстанови. Между другото, тогава той предоставяше техническа поддръжка непрекъснато в продължение на 14 часа подред на клиенти от Индия, Англия и Калифорния и едва тогава той можеше да започне да инсталира софтуера. След като завърши, той трябваше да разбере как работи всичко и да идентифицира всички възможни проблеми, с които потенциалните потребители могат да се сблъскат, за да реагират бързо на съответните искания от клиента.

Малко по-късно, през 2010 г., взех решение да въведа няколко нови функции в сайта, върху който работех тогава. Добавих нов банер, който уведомява посетителите за всички иновации и след 5 минути дистанционно влязох в сървъра и пуснах всички скриптове. Очевидно след половин минута всичко започна да работи и потребителите на сайта започнаха да дават обратна връзка. Вярно, те срещнаха тогава една грешка, която успях да отстраня един час по-късно.

Ускорен темп на развитие

През последните 20 години в сегмента на разработката на софтуер настъпиха значителни промени. Периодичното сканиране на уебсайтове е актуалната тенденция на нашето време, която постоянно се използва от компании като Facebook или GitHub, коригирайки собствените си сайтове десетки пъти всеки ден. Такива процеси възникват моментално — с едно щракване и цялата функционалност вече е преразпределена между различни потребителски групи. И в резултат се появяват все пак различни бъгове, въпреки че са изправени само няколко. Друго нещо е, че те са незначителни, те се поправят лесно, само няколко души ги виждат, а дори и тогава на ранните етапи, защото самият процес на развитие протича постепенно. Най-честият страничен ефект от коригирането на тези бъгове е забавяне на темповете на развитие.

Тъй като облачните услуги и инструменти са станали част от нашето ежедневие и непрекъснатите процеси на интеграция и стартиране стават по-достъпни, редовното тестване на QA става по-рядко и дори тогава е популярно сред малките екипи в ранните етапи на развитие. Затова днес, вместо да разгърнат нововъведение веднага след пълна проверка на здравето, малките екипи за разработка предпочитат да използват стратегия за отстраняване на грешки след факт, защото процесът е достатъчно бърз. Такъв подход, комбиниран с компетентно класиране на идентифицираните грешки, осигурява непрекъсната производителност на труда, темпове на развитие, което ни позволява да предложим на пазара все още работещ продукт.

Непрекъснатото развитие на младите компании днес се осигурява главно от способността да се организира строг автоматичен контрол върху инфраструктурата и набора от използван софтуер: например, чатбот може да предава информация на CI сървър, който сам ще стартира специфична компилация и ще осигури разполагане на няколко фирмени сървъра. Отново входящият трафик се разпределя съгласно предварително определени правила, пренасочвайки конкретни потребители към отделни сървъри. Неразопакованият код може да включва телеметрия, която позволява ранно откриване на грешки при отваряне и анулиране на този процес в автоматичен или ръчен режим.

Такива неща са норма днес, защото всяка компания използва собствени системи, независимо контролира кода и конфигурацията на всяка, а също така получава навреме цялата необходима телеметрия от цялото оборудване, налично в инфраструктурата, включително виртуалния софтуер.

Децентрализация

Сега нека разгледаме децентрализираните мрежи, които по принцип не се вписват в концепцията за „контрол“. Организацията на процеса на разработка, в резултат на което се получава добре конфигурирана децентрализирана мрежа, в най-добрия случай контролира само всички съществуващи възли. В същото време самият контрол се осъществява в ръчен режим, тъй като само живи хора следят мрежовата инфраструктура. Когато всички участници в мрежата използват различни възли едновременно, тяхното поведение е подобно на независимите участници, а самият процес на почистване става по-труден за контрол. При правилно конфигурирана децентрализирана мрежа, гарантирането на поверителността на тези, които управляват нейните възли, се превръща в ключов момент, тъй като телеметрията се предава паралелно, което повечето участници в мрежата може изобщо да не прехвърлят на разработчиците.

Вероятността да открием бъгове, засягащи определени категории потребители, също е малка. Но дори и това да е било успешно, не е толкова лесно бързо да ги изключите от всички участници наведнъж.

В известен смисъл, на този етап ние сме принудени да се върнем в началото на тази статия, защото говорим за инсталиране на кода в една конкретна система, без възможност за онлайн актуализация от разстояние. Резултатът от този подход ни е известен предварително — има грешки, които позволяват на атакуващите да откраднат милиони долари в етер (ETH) или бъгове, които пречат на милиони потребители да се свържат с мрежата. Могат да се правят и опити за заобикаляне на условията за децентрализация чрез централизиране на основни услуги. В някои случаи общността сама може да елиминира подобни грешки, но поради идеологически причини или невъзможността за бърза координация на собствените си действия това не винаги е възможно.

Минало, настояще … Запознайте се с бъдещето

И така как точно трябва да се справят разработчиците на децентрализирани мрежи с това ново състояние? Трябва ли да се откажат от принципите на постепенното, непрекъснато развитие или все още има средно положение? Струва ни се, че е имало някои ефективни решения на подобни проблеми, свързани с развитието на децентрализирани мрежи и преди, и можем да се възползваме от тях от миналото. Все пак трябва да имаме предвид самия опит на непрекъснато развитие, благодарение на което дори в условията на децентрализирани системи е възможно да се гарантира сигурността.

Стартирането на мрежата в тестов режим наистина ви позволява да експериментирате малко с някои иновации, защото с нея можете да симулирате прекъсване на възел, типични транзакции и всякакви други условия, характерни за текущата реалност, което дава възможност да се повиши нивото на сигурност, производителност и устойчивост на самите мрежи. За съжаление е невъзможно напълно да се симулират реалните условия, затова тестовите мрежи могат да се разглеждат само като допълнителен инструмент, но живите хора все пак ще трябва да носят отговорност за реалността.

Дългосрочните проекти, които изискват периодични актуализации, са несъвършени и незавършени, защото след стартирането им почти сигурно ще се изискват оперативни корекции. От друга страна, децентрализираните проекти изискват по-задълбочен подход дори след стартирането им, особено по отношение на аспектите на сигурността. На практика това означава, че в началото наборът от функции на такива проекти трябва да бъде минимален. В този смисъл е целесъобразно да се припомни теорията за минималния жизнеспособен продукт (MVP), която е разумна в случая, тъй като предварителните разходи за внедряване на пълноценен продукт винаги са по-високи, и следователно, първоначалното пускане на по-малко жизнеспособен проект с възможност за оценка на реалните нужди и нужди на „живото“ условията са по-подходящи.

Поддержка сообщества настоящих энтузиастов на ранних этапах развития децентрализованного проекта тоже является преимуществом, ведь такие операторы узлов сети с радостью будут тестировать новые версии и оперативно давать обратную связь. По мере развития такого сообщества степень вовлеченности в проект будет расти, что существенно упростит полноценную развертку. В таких условиях следует уделять много внимания развитию сообщества, которое будет доверять разработчикам и идти в нужном направлении, что даст возможность найти оптимальный баланс между самостоятельным управлением инфраструктурой проекта и управлением ею с помощью всего сообщества. Высокую степень доверия последнего можно обеспечить посредством использования наиболее успешных практик и высококачественного кода, что, в свою очередь, нивелирует возможные риски и будет больше мотивировать на появление любых нововведений.

Има много начини за използване на настоящи и минали преживявания в децентрализиран свят. Вярваме, че в следващите няколко седмици ще споделим и с вас нови идеи в това отношение, както и ще обсъдим нашите планове и ще разкажем какво правим, преди да представим първата версия на проекта Keep Network.

Благодаря на Джеймс Престуич и Брайтън Уилямс за участието им в ранните ревизии на тази статия.

Източник: https://blog.keep.network/development-fast-and-slow-2b9116c8c4d5

Открийте повече

Ако искате да знаете повече информация за Keep Network, тогава:

Следвайте ни в Reddit.

Вижте нашият WP.

Вижте нашият бизнес план.

Абонирайте се за актуализации по имейл.

Следвайте ни в Twitter.

Следвайте ни на Slack.

Присъединете се към ни в Telegram.