Многу луѓе се борат со Elasticsearch. Но, што се случува кога сакате да го користите за складирање на дневници „во особено голем волумен“? И дали е исто така безболно да се доживее неуспехот на некој од неколкуте центри за податоци? Каква архитектура треба да направите и на кои стапици ќе се сопнете?
Ние во Однокласници решивме да го искористиме elasticsearch за да го решиме проблемот со управувањето со дневниците и сега го споделуваме нашето искуство со Habr: и за архитектурата и за замките.
Јас сум Пјотр Зајцев, работам како системски администратор во Однокласници. Пред тоа бев и админ, работев со Manticore Search, Sphinx Search, Elasticsearch. Можеби, ако се појави друго ...пребарување, веројатно и јас ќе работам со него. Учествувам и во голем број проекти со отворен код на доброволна основа.
Кога дојдов во Однокласници, на интервјуто непромислено реков дека можам да работам со Elasticsearch. Откако се справив со тоа и завршив неколку едноставни задачи, ми беше дадена големата задача да го реформирам системот за управување со дневници што постоеше во тоа време.
Барања
Системските барања беа формулирани на следниов начин:
- Graylog требаше да се користи како преден дел. Бидејќи компанијата веќе имаше искуство со користење на овој производ, програмерите и тестерите го знаеја тоа, им беше познато и погодно.
- Обем на податоци: во просек 50-80 илјади пораки во секунда, но ако нешто се скрши, тогаш сообраќајот не е ограничен со ништо, може да биде 2-3 милиони линии во секунда
- Откако разговаравме со клиентите за барањата за брзина на обработка на барањата за пребарување, сфативме дека типичната шема на користење на таков систем е оваа: луѓето бараат дневници на нивната апликација во последните два дена и не сакаат да чекаат повеќе од второ за резултатот од формулираното барање.
- Администраторите инсистираа системот да биде лесно скалабилен доколку е потребно, без да бараат од нив длабоко да истражуваат како функционира.
- Така што единствената задача за одржување што овие системи ја бараат периодично е промена на одреден хардвер.
- Покрај тоа, Однокласниците има одлична техничка традиција: секоја услуга што ја лансираме мора да преживее дефект на центарот за податоци (ненадеен, непланиран и апсолутно во секое време).
Најмногу не чинеше последното барање во реализацијата на овој проект, за што ќе зборувам подетално.
Среда
Работиме во четири центри за податоци, додека јазлите за податоци на Elasticsearch можат да се лоцираат само во три (од голем број нетехнички причини).
Овие четири центри за податоци содржат приближно 18 илјади различни извори на дневници - хардвер, контејнери, виртуелни машини.
Важна карактеристика: кластерот започнува во контејнери не на физички машини, туку на . На контејнерите им се гарантираат 2 јадра, слични на 2.0 Ghz v4, со можност за рециклирање на преостанатите јадра доколку се во мирување.
Со други зборови:
Топологија
Првично ја видов општата форма на решението како што следува:
- Зад А-записот на доменот Graylog стојат 3-4 ВИП, ова е адресата на која се испраќаат дневниците.
- секој ВИП е LVS-балансер.
- После него, дневниците одат во батеријата на Graylog, дел од податоците се во формат GELF, некои во формат syslog.
- Потоа сето ова е напишано во големи серии на батерија од координатори на Elasticsearch.
- И тие, пак, испраќаат барања за пишување и читање до соодветните јазли на податоци.
Терминологија
Можеби не секој детално ја разбира терминологијата, па би сакал малку да се задржам на тоа.
Elasticsearch има неколку типови на јазли - господар, координатор, податочен јазол. Постојат два други типа за различни трансформации на дневници и комуникација помеѓу различни кластери, но ги користевме само наведените.
Господар
Ги пингува сите јазли присутни во кластерот, одржува ажурирана мапа на кластерот и ја дистрибуира помеѓу јазлите, ја обработува логиката на настани и врши различни видови на домаќинство на кластерот.
Координатор
Врши една единствена задача: прифаќа барања за читање или пишување од клиенти и го насочува овој сообраќај. Во случај да има барање за запишување, најверојатно, ќе го праша master во кој фрагмент од соодветниот индекс треба да го стави и ќе го пренасочи барањето понатаму.
Јазол на податоци
Зачувува податоци, врши барања за пребарување што пристигнуваат однадвор и врши операции на парчиња лоцирани на нив.
Грајог
Ова е нешто како спој на Кибана со Логсташ во оџак ELK. Graylog комбинира и интерфејс и цевковод за обработка на дневници. Под хаубата, Graylog работи Kafka и Zookeeper, кои обезбедуваат поврзување со Graylog како кластер. Graylog може да ги кешира дневниците (Kafka) во случај Elasticsearch да е недостапен и да повторува неуспешни барања за читање и пишување, групирање и обележување дневници според одредени правила. Како и Logstash, Graylog има функционалност да менува редови пред да ги запише на Elasticsearch.
Покрај тоа, Graylog има вградено откритие за услуги што овозможува, врз основа на еден достапен јазол Elasticsearch, да се добие целата мапа на кластерот и да се филтрира по одредена ознака, што овозможува да се насочат барањата до одредени контејнери.
Визуелно изгледа вака:
Ова е скриншот од одреден пример. Овде градиме хистограм врз основа на барањето за пребарување и прикажуваме соодветни редови.
Индекси
Враќајќи се на системската архитектура, би сакал подетално да се задржам на тоа како го изградивме индексниот модел, така што сето тоа функционира правилно.
На дијаграмот погоре, ова е најниското ниво: Elasticsearch податочни јазли.
Индексот е голем виртуелен ентитет составен од делови од Elasticsearch. Самиот по себе, секој од фрагментите не е ништо повеќе од Лусен индекс. И секој Lucene индекс, пак, се состои од еден или повеќе сегменти.
Кога дизајниравме, сфативме дека за да го исполниме условот за брзина на читање на голема количина на податоци, треба да ги „рашириме“ овие податоци рамномерно низ податочните јазли.
Ова резултираше со фактот дека бројот на парчиња по индекс (со реплики) треба да биде строго еднаков на бројот на јазли на податоци. Прво, за да обезбедиме фактор на репликација еднаков на два (односно, можеме да изгубиме половина од кластерот). И, второ, со цел да се обработат барањата за читање и пишување на најмалку половина од кластерот.
Прво го одредивме времето на складирање како 30 дена.
Распределбата на парчињата може графички да се претстави на следниов начин:
Целиот темносив правоаголник е индекс. Левиот црвен квадрат во него е примарен фрагмент, прв во индексот. И синиот квадрат е реплика на парченце. Тие се наоѓаат во различни центри за податоци.
Кога ќе додадеме уште еден фрагмент, тој оди во третиот центар за податоци. И, на крајот, ја добиваме оваа структура, што овозможува да се изгуби DC без губење на конзистентноста на податоците:
Ротација на индекси, т.е. создавајќи нов индекс и бришејќи го најстариот, го направивме еднаков на 48 часа (според шемата на користење на индексот: најчесто се пребаруваат последните 48 часа).
Овој интервал на ротација на индексот се должи на следниве причини:
Кога барањето за пребарување пристигнува до одреден податочен јазол, тогаш, од гледна точка на перформанси, попрофитабилно е кога се бара еден фрагмент, ако неговата големина е споредлива со големината на колкот на јазолот. Ова ви овозможува да го задржите „жешкиот“ дел од индексот во куп и брзо да пристапите до него. Кога има многу „жешки делови“, брзината на пребарување на индекси се намалува.
Кога јазолот започнува со извршување на барањето за пребарување на еден фрагмент, тој доделува број на нишки еднаков на бројот на хипернишки јадра на физичката машина. Ако барањето за пребарување влијае на голем број парчиња, тогаш бројот на нишки расте пропорционално. Ова има негативно влијание врз брзината на пребарување и негативно влијае на индексирањето на новите податоци.
За да ја обезбедиме потребната латентност за пребарување, решивме да користиме SSD. За брзо процесирање на барањата, машините што ги хостираа овие контејнери мораа да имаат најмалку 56 јадра. Бројката 56 е избрана како условно доволна вредност која го одредува бројот на нишки што ќе ги генерира Elasticsearch за време на работата. Во Elasitcsearch, многу параметри за базен на нишки директно зависат од бројот на достапни јадра, што пак директно влијае на потребниот број на јазли во кластерот според принципот „помалку јадра - повеќе јазли“.
Како резултат на тоа, откривме дека во просек еден фрагмент тежи околу 20 гигабајти, а има 1 парчиња по индекс. Според тоа, ако ги ротираме еднаш на 360 часа, тогаш имаме 48 од нив. Секој индекс содржи податоци за 15 дена.
Кола за пишување и читање податоци
Ајде да откриеме како се запишуваат податоците во овој систем.
Да речеме дека пристигнува некое барање од Грејлог до координаторот. На пример, сакаме да индексираме 2-3 илјади редови.
Координаторот, откако доби барање од Грејлог, го испрашува мајсторот: „Во барањето за индексирање, конкретно наведовме индекс, но во кој фрагмент да се напише не беше наведен“.
Господарот одговара: „Напишете ја оваа информација на фрагментот број 71“, по што се испраќа директно до соодветниот податочен јазол, каде што се наоѓа примарниот фрагмент број 71.
После тоа, дневникот за трансакции се реплицира на реплика-парче, која се наоѓа во друг центар за податоци.
Барање за пребарување пристигнува од Грејлог до координаторот. Координаторот го пренасочува според индексот, додека Elasticsearch ги дистрибуира барањата помеѓу примарниот и реплика-парчето користејќи го принципот на круг-робин.
180-те јазли реагираат нерамномерно, и додека тие реагираат, координаторот акумулира информации што веќе се „исфрлени“ од побрзи податочни јазли. По ова, кога или ќе пристигнат сите информации, или кога барањето ќе дојде до тајмаут, се дава директно на клиентот.
Целиот овој систем во просек ги обработува барањата за пребарување за последните 48 часа за 300-400 ms, исклучувајќи ги оние прашања со водечка џокер.
Цвеќиња со Elasticsearch: поставување Java
За сето тоа да функционира како што првично сакавме, поминавме многу долго време во дебагирање на широк спектар на работи во кластерот.
Првиот дел од откриените проблеми беше поврзан со начинот на кој Java е стандардно конфигурирана во Elasticsearch.
Проблем еден
Видовме многу голем број извештаи дека на ниво на Lucene, кога се извршуваат задачите во заднина, спојувањата на сегментите на Lucene не успеваат со грешка. Во исто време, беше јасно во дневниците дека ова е грешка OutOfMemoryError. Од телеметрија видовме дека колкот е слободен и не беше јасно зошто оваа операција не успева.
Се покажа дека спојувањата на Lucene индексот се случуваат надвор од колкот. И контејнерите се доста строго ограничени во однос на потрошените ресурси. Само купиштата можеше да се вклопат во овие ресурси (вредноста на heap.size беше приближно еднаква на RAM-от), а некои операции со off-heap паднаа со грешка во распределбата на меморијата ако поради некоја причина не се вклопат во ~500MB што остана пред ограничувањето.
Поправката беше прилично тривијална: количината на достапна RAM меморија за контејнерот беше зголемена, по што заборавивме дека дури и имавме такви проблеми.
Проблем два
4-5 дена по лансирањето на кластерот, забележавме дека јазлите на податоци почнаа периодично да паѓаат од кластерот и да влегуваат во него по 10-20 секунди.
Кога почнавме да го откриваме тоа, се покажа дека оваа меморија во Elasticsearch не се контролира на кој било начин. Кога му дадовме повеќе меморија на контејнерот, можевме да ги пополниме директните бафери со различни информации, и тој беше исчистен дури откако експлицитниот GC беше лансиран од Elasticsearch.
Во некои случаи, оваа операција траеше доста долго, и за тоа време кластерот успеа да го означи овој јазол како веќе излезен. Овој проблем е добро опишан .
Решението беше следново: ја ограничивме способноста на Јава да го користи најголемиот дел од меморијата надвор од купот за овие операции. Го ограничивме на 16 гигабајти (-XX:MaxDirectMemorySize=16g), осигурувајќи дека експлицитниот GC се повикува многу почесто и се обработува многу побрзо, со што повеќе нема да се дестабилизира кластерот.
Задача три
Ако мислите дека проблемите со „јазлите што го напуштаат кластерот во најнеочекуван момент“ се завршени, се лажете.
Кога ја конфигуриравме работата со индекси, избравме mmapfs да на свежи парчиња со голема сегментација. Ова беше прилично грешка, бидејќи кога се користи mmapfs датотеката се мапира во RAM меморијата, а потоа работиме со мапираната датотека. Поради ова, излегува дека кога GC се обидува да ги запре нишките во апликацијата, ние одиме на безбедносната точка многу долго, а на пат до неа, апликацијата престанува да одговара на барањата на мајсторот за тоа дали е жива . Според тоа, господарот верува дека јазолот повеќе не е присутен во кластерот. По ова, по 5-10 секунди, собирачот на ѓубре работи, јазолот оживува, повторно влегува во кластерот и започнува со иницијализирање на парчиња. Сето тоа многу личеше на „продукција што ја заслуживме“ и не беше соодветно за ништо сериозно.
За да се ослободиме од ваквото однесување, прво се префрливме на стандардни niofs, а потоа, кога мигриравме од петтата верзија на Elastic на шестата, пробавме хибридфови, каде што овој проблем не беше репродуциран. Можете да прочитате повеќе за типовите на складирање .
Задача четири
Потоа имаше уште еден многу интересен проблем кој го третиравме рекордно време. Го фативме 2-3 месеци затоа што неговиот модел беше апсолутно неразбирлив.
Понекогаш нашите координатори одеа во Full GC, обично некаде по ручекот, и никогаш не се враќаа оттаму. Во исто време, при евидентирање на доцнењето на GC, изгледаше вака: сè оди добро, добро, добро, а потоа одеднаш сè оди многу лошо.
Отпрвин мислевме дека имаме злобен корисник кој упатува некакво барање што го исфрли координаторот од режим на работа. Ги евидентиравме барањата многу долго, обидувајќи се да откриеме што се случува.
Како резултат на тоа, се покажа дека во моментот кога корисникот ќе започне огромно барање и ќе стигне до специфичен координатор на Elasticsearch, некои јазли реагираат подолго од другите.
И додека координаторот чека одговор од сите јазли, тој ги акумулира резултатите испратени од јазлите кои веќе одговориле. За GC, ова значи дека нашите шеми за користење купишта се менуваат многу брзо. И GC што го користевме не можеше да се справи со оваа задача.
Единственото решение што го најдовме за да го промениме однесувањето на кластерот во оваа ситуација е миграцијата во JDK13 и користењето на собирачот на ѓубре Шенандоа. Ова го реши проблемот, нашите координатори престанаа да паѓаат.
Тука завршија проблемите со Java и започнаа проблемите со пропусниот опсег.
„Бобинки“ со Elasticsearch: пропусната моќ
Проблемите со пропусната моќ значат дека нашиот кластер работи стабилно, но при максимум во бројот на индексирани документи и за време на маневри, перформансите се недоволни.
Првиот симптом што се среќава: за време на некои „експлозии“ во производството, кога ненадејно се генерираат многу голем број дневници, грешката при индексирање es_rejected_execution почнува често да трепка во Graylog.
Ова се должи на фактот што thread_pool.write.queue на еден податочен јазол, сè до моментот кога Elasticsearch може да го обработи барањето за индексирање и да ги постави информациите на фрагментот на дискот, може стандардно да кешира само 200 барања. И во Многу малку се зборува за овој параметар. Наведени се само максималниот број на нишки и стандардната големина.
Се разбира, отидовме да ја извртиме оваа вредност и го дознавме следново: конкретно, во нашето поставување, до 300 барања се кеширани доста добро, а повисока вредност е полн со фактот дека повторно летаме во Full GC.
Дополнително, бидејќи се работи за серии на пораки кои пристигнуваат во рамките на едно барање, неопходно беше да се прилагоди Graylog за да не пишува често и во мали серии, туку во огромни серии или еднаш на секои 3 секунди, ако серијата сè уште не е завршена. Во овој случај, излегува дека информациите што ги пишуваме во Elasticsearch стануваат достапни не за две секунди, туку за пет (што многу ни одговараат), туку бројот на повторени табли што треба да се направат за да се пробие низ голем купот на информации е намален.
Ова е особено важно во оние моменти кога нешто се срушило некаде и бесно известува за тоа, за да не се добие целосно спамиран Еластик, а по некое време - Graylog јазли кои се нефункционални поради затнати бафери.
Дополнително, кога ги имавме истите овие експлозии во производството, добивме поплаки од програмери и тестери: во моментот кога навистина им беа потребни овие трупци, им беа дадени многу бавно.
Почнаа да го сфаќаат тоа. Од една страна, беше јасно дека и барањата за пребарување и прашањата за индексирање беа обработени, во суштина, на истите физички машини, и на еден или друг начин ќе има одредени повлекувања.
Но, ова може делумно да се заобиколи поради фактот што во шестата верзија на Elasticsearch, се појави алгоритам кој ви овозможува да дистрибуирате прашања помеѓу релевантните јазли на податоци не според принципот на случаен круг-робин (контејнерот што прави индексирање и го држи примарниот -shard може да биде многу зафатен, нема да има начин да се одговори брзо), но ова барање да се препрати во помалку натоварен контејнер со реплика-shard, кој ќе одговори многу побрзо. Со други зборови, стигнавме до use_adaptive_replica_selection: точно.
Сликата за читање почнува да изгледа вака:
Преминот кон овој алгоритам овозможи значително да се подобри времето на барање во оние моменти кога имавме голем проток на дневници за пишување.
Конечно, главниот проблем беше безболното отстранување на центарот за податоци.
Што сакавме од кластерот веднаш по губењето на врската со еден DC:
- Ако имаме тековен господар во неуспешниот центар за податоци, тогаш тој ќе биде повторно избран и преместен како улога во друг јазол во друг DC.
- Господарот брзо ќе ги отстрани сите недостапни јазли од кластерот.
- Врз основа на преостанатите, тој ќе разбере: во изгубениот центар за податоци имавме такви и такви примарни фрагменти, тој брзо ќе промовира дополнителни парчиња реплика во преостанатите центри за податоци, а ние ќе продолжиме со индексирање на податоците.
- Како резултат на ова, протокот на пишување и читање на кластерот постепено ќе се деградира, но генерално сè ќе функционира, иако бавно, но стабилно.
Како што се испостави, сакавме вакво нешто:
И го добивме следново:
Како се случи ова?
Кога центарот за податоци падна, нашиот господар стана тесно грло.
Зошто?
Факт е дека мајсторот има TaskBatcher, кој е одговорен за дистрибуција на одредени задачи и настани во кластерот. Секое излегување од јазол, секоја промоција на фрагмент од реплика во примарна, каква било задача да се создаде фрагмент некаде - сето ова оди прво до TaskBatcher, каде што се обработува последователно и во една нишка.
Во моментот на повлекување на еден центар за податоци, се покажа дека сите јазли на податоци во преживеаните центри за податоци сметаа дека е нивна должност да го информираат господарот „изгубивме такви и такви парчиња и такви и такви јазли на податоци“.
Во исто време, преживеаните јазли на податоци ги испратија сите овие информации до сегашниот господар и се обидоа да чекаат потврда дека тој ги прифатил. Тие не го чекаа ова, бидејќи мајсторот добиваше задачи побрзо отколку што можеше да одговори. Јазлите го прекинаа времето за повторување на барањата, а господарот во овој момент не се ни обиде да одговори на нив, туку беше целосно апсорбиран во задачата да ги сортира барањата по приоритет.
Во терминална форма, се покажа дека јазлите на податоци го спамирале господарот до тој степен што тој отишол во целосен GC. После тоа, нашата главна улога се пресели во некој следен јазол, апсолутно истото се случи и со него, и како резултат на кластерот целосно се распадна.
Направивме мерења и пред верзијата 6.4.0, каде што ова беше поправено, ни беше доволно истовремено да излеземе само 10 податочни јазли од 360 за целосно да го исклучиме кластерот.
Изгледаше нешто вака:
По верзијата 6.4.0, каде што беше поправена оваа ужасна грешка, јазлите на податоци престанаа да го убиваат господарот. Но, тоа не го направи „попаметен“. Имено: кога ќе излеземе 2, 3 или 10 (кој било број различен од еден) податочни јазли, господарот добива некоја прва порака која вели дека јазолот А заминал и се обидува да му каже на јазолот B, јазолот C за ова, јазолот D.
И во моментов, ова може да се реши само со поставување на тајмаут за обидите да се каже некому за нешто, еднакво на околу 20-30 секунди, и на тој начин да се контролира брзината на движењето на центарот за податоци надвор од кластерот.
Во принцип, ова се вклопува во барањата што првично беа претставени на финалниот производ како дел од проектот, но од гледна точка на „чиста наука“ ова е грешка. Што, патем, беше успешно поправено од програмерите во верзијата 7.2.
Освен тоа, кога изгасна одреден јазол на податоци, се покажа дека ширењето информации за неговото излегување е поважно отколку да се каже на целиот кластер дека има такви и такви примарни делови на него (со цел да се промовира реплика-парче во други податоци центар во основно, а на нив би можело да се пишува во информација).
Затоа, кога сè е веќе изумрено, објавените јазли на податоци не се веднаш означени како застарени. Соодветно на тоа, ние сме принудени да чекаме додека сите пингови не истечат до објавените јазли на податоци, и само после тоа нашиот кластер почнува да ни кажува дека таму, таму и таму треба да продолжиме да снимаме информации. Можете да прочитате повеќе за ова .
Како резултат на тоа, операцијата за повлекување на центарот за податоци денес ни одзема околу 5 минути за време на шпицот. За толку голем и несмасен колос, ова е прилично добар резултат.
Како резултат на тоа, дојдовме до следнава одлука:
- Имаме 360 јазли на податоци со дискови од 700 гигабајти.
- 60 координатори за рутирање на сообраќајот низ истите тие податочни јазли.
- 40 мајстори што ги оставивме како своевидно наследство од верзиите пред 6.4.0 - за да го преживееме повлекувањето на центарот за податоци, психички бевме подготвени да изгубиме неколку машини за да ни се гарантира дека ќе имаме кворум на мајстори дури и во најлошото сценарио
- Сите обиди да се комбинираат улогите на еден контејнер беа исполнети со фактот дека порано или подоцна јазолот ќе се скрши под оптоварување.
- Целиот кластер користи heap.size од 31 гигабајти: сите обиди за намалување на големината резултираа или со убивање на некои јазли при тешки барања за пребарување со водечката џокер или со добивање на прекинувачот во самиот Elasticsearch.
- Дополнително, за да обезбедиме перформанси за пребарување, се обидовме да го задржиме бројот на објекти во кластерот што е можно помал, со цел да обработиме што е можно помалку настани во тесното грло што го добивме во главниот.
Конечно за мониторингот
За да се осигураме дека сето ова функционира како што е планирано, го следиме следново:
- Секој податочен јазол известува до нашиот облак дека постои, и има такви и такви парчиња на него. Кога ќе изгаснеме нешто некаде, кластерот по 2-3 секунди известува дека во центарот А ги изгаснавме јазлите 2, 3 и 4 - тоа значи дека во другите центри за податоци ние во никој случај не можеме да ги изгаснеме оние јазли на кои има само еден дел. лево.
- Знаејќи ја природата на однесувањето на мајсторот, многу внимателно го разгледуваме бројот на нерешени задачи. Бидејќи дури и една заглавена задача, ако не истече на време, теоретски во некоја итна ситуација може да стане причина зошто, на пример, промоцијата на фрагмент од реплика во основното не функционира, поради што индексирањето ќе престане да работи.
- Исто така, многу внимателно ги разгледуваме доцнењата на собирачите на ѓубре, бидејќи веќе имавме големи тешкотии со ова за време на оптимизацијата.
- Отфрла со конец за да се разбере однапред каде е тесното грло.
- Па, стандардни метрики како што се куп, RAM и I/O.
При градење на мониторинг, мора да ги земете предвид карактеристиките на Thread Pool во Elasticsearch. ги опишува опциите за конфигурација и стандардните вредности за пребарување и индексирање, но е целосно тивок за thread_pool.management. Овие нишки обработуваат, особено, прашања како _cat/shards и други слични, кои се погодни за користење при пишување следење. Колку е поголем кластерот, толку повеќе такви барања се извршуваат по единица време, а гореспоменатото thread_pool.management не само што не е претставено во официјалната документација, туку е стандардно ограничено на 5 нишки, што многу брзо се отстранува, по кој мониторинг престанува да работи правилно.
Што сакам да кажам како заклучок: го направивме тоа! Можевме да им дадеме на нашите програмери и програмери алатка која, во речиси секоја ситуација, може брзо и сигурно да обезбеди информации за тоа што се случува во производството.
Да, се покажа доста комплицирано, но, сепак, успеавме да ги вклопиме нашите желби во постоечките производи, кои не моравме сами да ги закрпиме и препишуваме.
Извор: www.habr.com