Мониторингът мъртъв ли е? — Да живее наблюдението

От 2008 г. нашата компания се занимава предимно с управление на инфраструктурата и денонощна техническа поддръжка за уеб проекти: имаме повече от 400 клиента, което е около 15% от руската електронна търговия. Съответно се поддържа много разнообразна архитектура. Ако нещо падне, сме длъжни да го поправим в рамките на 15 минути. Но за да разберете, че е настъпил инцидент, трябва да наблюдавате проекта и да реагирате на инциденти. Как да стане това?

Смятам, че има проблем с организирането на правилна система за мониторинг. Ако нямаше проблеми, тогава моята реч щеше да се състои от една теза: „Моля, инсталирайте Prometheus + Grafana и плъгини 1, 2, 3.“ За съжаление вече не работи по този начин. И основният проблем е, че всички продължават да вярват в нещо, което съществуваше през 2008 г., по отношение на софтуерните компоненти.

Относно организацията на системата за мониторинг бих си позволил да кажа, че... проекти с компетентен мониторинг не съществуват. И ситуацията е толкова лоша, че ако нещо падне, има риск да остане незабелязано - в крайна сметка всички са сигурни, че „всичко се следи“.
Може би всичко се следи. Но как?

Всички сме се сблъсквали с история като следната: определен devops, определен администратор работи, екип за разработка идва при тях и казва - „освободени сме, сега наблюдавайте“. Монитор какво? Как работи?

ДОБРЕ. Ние наблюдаваме по старомодния начин. И вече се променя и се оказва, че сте наблюдавали услуга A, която е станала услуга B, която взаимодейства с услуга C. Но екипът за разработка ви казва: „Инсталирайте софтуера, той трябва да следи всичко!“

И така, какво се промени? - Всичко се е променило!

2008 г Всичко е наред

Има няколко разработчици, един сървър, един сървър на база данни. Всичко тръгва оттук. Имаме малко информация, инсталираме zabbix, Nagios, cacti. И след това задаваме ясни сигнали за процесора, за дисковата работа и за дисковото пространство. Извършваме и няколко ръчни проверки, за да гарантираме, че сайтът реагира и че поръчките пристигат в базата данни. И това е – повече или по-малко сме защитени.

Ако сравним количеството работа, която администраторът е свършил след това, за да осигури наблюдение, тогава 98% от нея е било автоматично: лицето, което извършва наблюдението, трябва да разбере как да инсталира Zabbix, как да го конфигурира и да конфигурира предупреждения. И 2% - за външни проверки: дали сайтът отговаря и прави заявка към базата данни, че са пристигнали нови поръчки.

2010 г Натоварването расте

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

Освен това субектът, свързан с инфраструктурата, все още остава най-големият в главата на мениджъра. Все още има идея в главата ми, че човекът, който извършва мониторинг, е човекът, който ще инсталира zabbix и ще може да го конфигурира.

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

Забележка: Написах „набор от скриптове“ 3 пъти. Тоест лицето, отговорно за наблюдението, вече не е това, което просто инсталира zabbix. Това е човек, който започва да кодира. Но все още нищо не се е променило в съзнанието на отбора.

Но светът се променя, става все по-сложен. Добавени са слой за виртуализация и няколко нови системи. Те започват да взаимодействат помежду си. Кой каза, че „мирише на микроуслуги?“ Но всяка услуга все още изглежда като уебсайт поотделно. Можем да се обърнем към него и да разберем, че той предоставя необходимата информация и работи сам. И ако си администратор, постоянно участващ в проект, който се развива 5-7-10 години, това знание се натрупва: появява се ново ниво - осъзнал си го, появява се друго ниво - осъзнал си го...

Но рядко някой съпровожда проект 10 години.

Резюме на Monitoringman

Да предположим, че сте попаднали в нов стартъп, който веднага е наел 20 разработчици, написал е 15 микроуслуги и вие сте администратор, на когото е казано: „Създайте CI/CD. Моля те." Създали сте CI/CD и изведнъж чувате: „Трудно ни е да работим с производство в „куб“, без да разбираме как ще работи приложението в него. Направете ни пясъчна кутия в същия „куб“.
Вие правите пясъчник в този куб. Те веднага ви казват: „Искаме етапна база данни, която се актуализира всеки ден от производството, така че да разберем, че работи в базата данни, но в същото време да не разваля производствената база данни.“

Вие живеете във всичко това. Остават 2 седмици до излизането, казват ви: „А сега да следим всичко това...“ Т.е. наблюдавайте клъстерната инфраструктура, наблюдавайте архитектурата на микросервизите, наблюдавайте работата с външни услуги...

И моите колеги изваждат от главите си обичайната схема и казват: „Е, тук всичко е ясно! Инсталирайте програма, която ще следи всичко това. Да, да: Prometheus + Grafana + плъгини.
И добавят: "Имате две седмици, уверете се, че всичко е сигурно."

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

• Той трябва да разбира мониторинга и спецификата на работата на желязната инфраструктура.
• Той трябва да разбере спецификата на наблюдението на Kubernetes (и всеки иска да отиде в „куба“, защото можете да се абстрахирате от всичко, да се скриете, защото администраторът ще се справи с останалото) - себе си, неговата инфраструктура и да разбере как да наблюдава приложенията вътре.
• Той трябва да разбере, че услугите комуникират помежду си по специални начини и да знае спецификата на това как услугите взаимодействат помежду си. Напълно възможно е да видите проект, в който някои услуги комуникират синхронно, защото няма друг начин. Например бекендът преминава през REST, през gRPC към каталожната услуга, получава списък с продукти и го връща обратно. Не можеш да чакаш тук. И с други услуги работи асинхронно. Прехвърлете поръчката на услугата за доставка, изпратете писмо и т.н.
  Вероятно вече сте плували от всичко това? И админът, който трябва да следи това, се обърка още повече.
• Той трябва да може да планира и планира правилно - тъй като работата става все повече и повече.
• Следователно той трябва да създаде стратегия от създадената услуга, за да разбере как конкретно да я наблюдава. Той се нуждае от разбиране на архитектурата на проекта и неговото развитие + разбиране на технологиите, използвани при разработването.

Нека си спомним един абсолютно нормален случай: някои услуги са в PHP, някои услуги са в Go, някои услуги са в JS. Те по някакъв начин работят един с друг. Ето откъде идва терминът „микроуслуга“: има толкова много отделни системи, че разработчиците не могат да разберат проекта като цяло. Една част от екипа пише услуги в JS, които работят сами и не знаят как работи останалата част от системата. Другата част пише услуги в Python и не се намесва в работата на другите услуги; те са изолирани в собствената си област. Третият е писане на услуги на PHP или нещо друго.
Всичките тези 20 души са разпределени в 15 служби и има само един администратор, който трябва да разбере всичко това. Спри се! ние просто разделихме системата на 15 микроуслуги, защото 20 души не могат да разберат цялата система.

Но трябва да се следи по някакъв начин...

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

Какво да кажа... Хюстън, имаме проблеми.

Мониторингът на модерен софтуерен проект сам по себе си е софтуерен проект

От погрешното убеждение, че наблюдението е софтуер, ние развиваме вяра в чудеса. Но чудеса, уви, не се случват. Не можете да инсталирате zabbix и да очаквате всичко да работи. Няма смисъл да инсталираш Grafana и да се надяваш, че всичко ще е наред. По-голямата част от времето ще бъде изразходвано за организиране на проверки на работата на услугите и тяхното взаимодействие помежду си, проверка на това как работят външните системи. Всъщност 90% от времето ще бъде изразходвано не за писане на скриптове, а за разработване на софтуер. И трябва да се занимава с екип, който разбира работата по проекта.
Ако в тази ситуация един човек бъде хвърлен в наблюдение, тогава ще се случи бедствие. Което се случва навсякъде.

Например, има няколко услуги, които комуникират помежду си чрез Kafka. Поръчката пристигна, изпратихме съобщение за поръчката на Кафка. Има услуга, която слуша информация за поръчката и изпраща стоките. Има услуга, която слуша информация за поръчката и изпраща писмо до потребителя. И тогава се появяват още куп услуги и започваме да се объркваме.

И ако също дадете това на администратора и разработчиците на етапа, когато остава малко време преди пускането, лицето ще трябва да разбере целия този протокол. Тези. Проект от такъв мащаб отнема значително време и това трябва да се вземе предвид при разработването на системата.
Но много често, особено при стартиращи компании, виждаме как мониторингът се отлага за по-късно. „Сега ще направим доказателство за концепцията, ще стартираме с него, ще го оставим да падне – готови сме да се жертваме. И тогава ще наблюдаваме всичко. Когато (или ако) проектът започне да печели пари, бизнесът иска да добави още повече функции - защото той е започнал да работи, така че трябва да бъде разгърнат допълнително! И вие сте в момента, в който първо трябва да наблюдавате всичко предишно, което отнема не 1% от времето, а много повече. И между другото, разработчиците ще са необходими за наблюдение и е по-лесно да им позволите да работят върху нови функции. В резултат на това се пишат нови функции, всичко се прецаква и вие сте в безкрайна безизходица.

И така, как да наблюдавате проект, като започнете от самото начало и какво да направите, ако получите проект, който трябва да бъде наблюдаван, но не знаете откъде да започнете?

Първо, трябва да планирате.

Лирично отклонение: много често те започват с мониторинг на инфраструктурата. Например имаме Kubernetes. Нека започнем с инсталирането на Prometheus с Grafana, инсталирането на добавки за наблюдение на „куба“. Не само разработчиците, но и администраторите имат неприятната практика на: „Ще инсталираме този плъгин, но плъгинът вероятно знае как да го направи.“ Хората обичат да започват с простите и ясни, а не с важните действия. А наблюдението на инфраструктурата е лесно.

Първо решете какво и как искате да наблюдавате и след това изберете инструмент, защото други хора не могат да мислят вместо вас. И трябва ли? Други хора са мислили за универсална система - или изобщо не са мислили, когато е бил написан този плъгин. И това, че този плъгин има 5 хиляди потребители, не означава, че е от полза. Може би ще станете 5001-вият просто защото там вече е имало 5000 души.

Ако започнете да наблюдавате инфраструктурата и задната част на вашето приложение спре да отговаря, всички потребители ще загубят връзка с мобилното приложение. Ще се появи грешка. Те ще дойдат при вас и ще ви кажат „Приложението не работи, какво правите тук?“ - "Ние наблюдаваме." — „Как наблюдавате, ако не виждате, че приложението не работи?!»

1. Вярвам, че трябва да започнете да наблюдавате точно от входната точка на потребителя. Ако потребителят не вижда, че приложението работи, това е, това е грешка. И системата за мониторинг трябва първо да предупреди за това.
2. И едва тогава можем да наблюдаваме инфраструктурата. Или го направете паралелно. По-лесно е с инфраструктурата - тук най-накрая можем просто да инсталираме zabbix.
3. И сега трябва да отидете до корените на приложението, за да разберете къде нещата не работят.

Основната ми идея е мониторингът да върви успоредно с процеса на разработка. Ако разсеете екипа за наблюдение за други задачи (създаване на CI/CD, пясъчна среда, реорганизация на инфраструктурата), наблюдението ще започне да изостава и може никога да не наваксате развитието (или рано или късно ще трябва да го спрете).

Всичко по нива

Така виждам организацията на една система за мониторинг.

1) Ниво на приложение:

• мониторинг на бизнес логиката на приложението;
• Мониторинг на здравни показатели на услугите;
• интеграционен мониторинг.

2) Ниво на инфраструктура:

• мониторинг на нивото на оркестрация;
• мониторинг на системния софтуер;
• мониторинг на нивото на желязото.

3) Отново нивото на приложение - но като инженерен продукт:

• събиране и наблюдение на регистрационни файлове на приложения;
• APM;
• проследяване.

4) Предупреждение:

• организиране на система за предупреждение;
• организиране на дежурна система;
• организиране на „база от знания“ и работен процес за обработка на инциденти.

Важно е: стигаме до сигнала не след това, а веднага! Няма нужда да стартирате мониторинг и „някак по-късно“ да разберете кой ще получава сигнали. В края на краищата, каква е задачата на мониторинга: да разбере къде в системата нещо не работи и да уведоми правилните хора за това. Ако оставите това до края, тогава правилните хора ще разберат, че нещо се обърка само като викат „нищо не работи за нас“.

Приложен слой - Наблюдение на бизнес логиката

Тук говорим за проверка на самия факт, че приложението работи за потребителя.

Това ниво трябва да се направи по време на фазата на разработка. Например, имаме условен Prometheus: той отива до сървъра, който прави проверките, изтегля крайната точка, а крайната точка отива и проверява API.

Когато често се иска да наблюдават началната страница, за да се уверят, че сайтът работи, програмистите дават манипулатор, който може да бъде изтеглен всеки път, когато трябва да се уверят, че API работи. И програмистите в този момент все още вземат и пишат /api/test/helloworld
Единственият начин да се уверите, че всичко работи? - Не!

• Създаването на такива проверки по същество е задача на разработчиците. Единичните тестове трябва да се пишат от програмистите, които пишат кода. Защото, ако го изтече на администратора, „Пич, ето списък с API протоколи за всичките 25 функции, моля, наблюдавайте всичко!“ - нищо няма да се получи.
• Ако отпечатате „здравей свят“, никой никога няма да разбере, че API трябва и работи. Всяка промяна на API трябва да доведе до промяна в проверките.
• Ако вече имате такъв проблем, спрете функциите и разпределете разработчиците, които ще напишат тези проверки, или приемете загубите, приемете, че нищо не е проверено и ще се провали.

Технически съвети:

• Не забравяйте да организирате външен сървър за организиране на проверки - трябва да сте сигурни, че вашият проект е достъпен за външния свят.
• Организирайте проверки в целия API протокол, а не само в отделни крайни точки.
• Създайте крайна точка на прометей с резултатите от теста.

Приложен слой - мониторинг на показателите за здравето

Сега говорим за външни здравни показатели на услугите.

Решихме да наблюдаваме всички „ръкохватки“ на приложението с помощта на външни проверки, които извикваме от външна система за наблюдение. Но това са „дръжките“, които потребителят „вижда“. Искаме да сме сигурни, че самите ни услуги работят. Тук има по-добра история: K8s има проверки на здравето, така че поне самият „куб“ може да бъде убеден, че услугата работи. Но половината от чековете, които съм виждал, са със същия печат „здравей свят“. Тези. Така че той дърпа веднъж след разгръщането, той отговори, че всичко е наред - това е всичко. А услугата, ако предоставя собствен API, има огромен брой входни точки за същия API, който също трябва да бъде наблюдаван, защото искаме да знаем, че работи. И вече го наблюдаваме вътре.

Как да приложим това правилно технически: всяка услуга излага крайна точка за текущата си производителност и в графиките на Grafana (или всяко друго приложение) виждаме състоянието на всички услуги.

• Всяка промяна на API трябва да доведе до промяна в проверките.
• Създайте нова услуга веднага с показатели за здравето.
• Администраторът може да дойде при разработчиците и да поиска „добавете ми няколко функции, за да разбера всичко и да добавя информация за това към моята система за наблюдение.“ Но разработчиците обикновено отговарят: „Няма да добавяме нищо две седмици преди изданието.“
  Уведомете мениджърите по развитие, че ще има такива загуби, уведомете и ръководството на мениджърите по развитие. Защото когато всичко падне, някой пак ще се обади и ще поиска да следи „постоянно падащата услуга“ (c)
• Между другото, разпределете разработчиците да пишат плъгини за Grafana - това ще бъде добра помощ за администраторите.

Приложен слой - Мониторинг на интеграцията

Мониторингът на интеграцията се фокусира върху мониторинга на комуникациите между критични за бизнеса системи.

Например има 15 услуги, които комуникират помежду си. Това вече не са отделни сайтове. Тези. не можем да изтеглим услугата сама, да получим /helloworld и да разберем, че услугата работи. Тъй като уеб услугата за поръчка трябва да изпрати информация за поръчката до автобуса - от автобуса, складовата услуга трябва да получи това съобщение и да работи с него по-нататък. И услугата за разпространение на имейл трябва да обработи това по някакъв начин допълнително и т.н.

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

Какво препоръчвам да направите:

• За синхронна комуникация: крайната точка прави заявки към свързани услуги. Тези. вземаме тази крайна точка, изтегляме скрипт вътре в услугата, който отива до всички точки и казва „Мога да тегля там, и тегля там, мога да тегля там...“
• За асинхронна комуникация: входящи съобщения - крайната точка проверява шината за тестови съобщения и показва състоянието на обработка.
• За асинхронна комуникация: изходящи съобщения - крайната точка изпраща тестови съобщения към шината.

Както обикновено се случва: имаме услуга, която хвърля данни в автобуса. Ние идваме на тази услуга и ви молим да ни кажете за нейното състояние на интеграция. И ако услугата трябва да произведе съобщение някъде по-нататък (WebApp), тогава тя ще произведе това тестово съобщение. И ако стартираме услуга от страна на OrderProcessing, тя първо публикува това, което може да публикува независимо, и ако има някои зависими неща, тогава тя чете набор от тестови съобщения от автобуса, разбира, че може да ги обработва, докладва и , ако е необходимо, публикувайте ги допълнително и за това той казва - всичко е наред, жив съм.

Много често чуваме въпроса „как можем да тестваме това върху бойни данни?“ Например, говорим за една и съща услуга за поръчка. Поръчката изпраща съобщения до склада, където стоките са отписани: не можем да тестваме това върху бойни данни, защото „моите стоки ще бъдат отписани!“ Решението е да планирате целия този тест в самото начало. Имате и единични тестове, които правят подигравки. Така че, направете го на по-дълбоко ниво, където имате комуникационен канал, който не вреди на работата на бизнеса.

Инфраструктурно ниво

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

• Мониторингът на инфраструктурата може и трябва да бъде стартиран като отделен процес.
• Не трябва да започвате с мониторинг на инфраструктурата на работещ проект, дори ако наистина искате. Това е болка за всички devops. „Първо ще наблюдавам клъстера, ще наблюдавам инфраструктурата“ – т.е. Първо, ще следи какво се крие по-долу, но няма да влезе в приложението. Тъй като приложението е нещо неразбираемо за devops. Изтекло му е и той не разбира как работи. И той разбира инфраструктурата и започва с нея. Но не - винаги първо трябва да наблюдавате приложението.
• Не прекалявайте с броя на сигналите. Като се има предвид сложността на съвременните системи, предупрежденията летят непрекъснато и трябва по някакъв начин да живеете с този куп сигнали. И човекът на повикване, след като погледне сто от следващите сигнали, ще реши „Не искам да мисля за това“. Сигналите трябва да уведомяват само за критични неща.

Приложно ниво като бизнес единица

Ключови точки:

• ЕЛК. Това е индустриалният стандарт. Ако по някаква причина не събирате регистрационни файлове, започнете да го правите незабавно.
• APM. Външни APM като начин за бързо затваряне на мониторинг на приложения (NewRelic, BlackFire, Datadog). Можете временно да инсталирате това нещо, за да разберете поне по някакъв начин какво се случва с вас.
• Проследяване. В десетки микроуслуги трябва да проследите всичко, защото заявката вече не живее сама. Много е трудно да се добави по-късно, така че е по-добре незабавно да планирате проследяване в разработка - това е работата и полезността на разработчиците. Ако все още не сте го приложили, приложете го! Вижте Jaeger/Zipkin

Предупреждаване

• Организация на система за уведомяване: в условията на наблюдение на куп неща трябва да има единна система за изпращане на уведомления. Може в Графана. На запад всички използват PagerDuty. Сигналите трябва да са ясни (напр. откъде идват...). И е препоръчително да контролирате дали известията изобщо се получават
• Организация на дежурна система: сигналите не трябва да се изпращат до всички (или всички ще реагират в тълпата, или никой няма да реагира). Разработчиците също трябва да бъдат дежурни: не забравяйте да определите областите на отговорност, да направите ясни инструкции и да напишете в тях на кого точно да се обадите в понеделник и сряда и на кого да се обадите във вторник и петък (в противен случай те няма да се обадят на никого дори в случай на голям проблем - те ще се страхуват да ви събудят или да ви безпокоят: хората обикновено не обичат да се обаждат и да будят други хора, особено през нощта). И обяснете, че молбата за помощ не е показател за некомпетентност („Аз моля за помощ, това означава, че съм лош работник“), насърчавайте молбите за помощ.
• Организация на „база от знания“ и работен процес за обработка на инциденти: за всеки сериозен инцидент трябва да се планира следсмъртно изследване и като временна мярка трябва да се записват действията, които ще разрешат инцидента. И направете практика, че повтарящите се сигнали са грях; те трябва да бъдат фиксирани в код или инфраструктурна работа.

Технологичен стек

Нека си представим, че нашият стек е както следва:

• събиране на данни - Прометей + Графана;
• лог анализ - ELK;
• за APM или Tracing - Jaeger (Zipkin).

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

Няколко технически точки, които виждам навсякъде напоследък:

Прометей се набутва в Kubernetes - кой го измисли?! Ако вашият клъстер се срине, какво ще направите? Ако имате сложен клъстер вътре, тогава трябва да има някаква система за наблюдение вътре в клъстера и някаква отвън, която ще събира данни от вътрешността на клъстера.

Вътре в клъстера събираме трупи и всичко останало. Но системата за наблюдение трябва да е отвън. Много често в клъстер, където Promtheus е инсталиран вътрешно, има и системи, които извършват външни проверки на работата на сайта. Ами ако връзките ви с външния свят са прекъснали и приложението не работи? Оказва се, че вътре всичко е наред, но това не улеснява потребителите.

Данни

• Мониторингът на развитието не е инсталирането на помощни програми, а разработването на софтуерен продукт. 98% от днешния мониторинг е кодиране. Кодиране в услуги, кодиране на външни проверки, проверка на външни услуги и това е всичко.
• Не губете времето на вашите разработчици за наблюдение: това може да отнеме до 30% от работата им, но си заслужава.
• Devops, не се притеснявайте, че не можете да наблюдавате нещо, защото някои неща са напълно различен начин на мислене. Ти не си бил програмист, а следенето на работата е точно тяхна работа.
• Ако проектът вече работи и не се наблюдава (а вие сте мениджър), разпределете ресурси за наблюдение.
• Ако продуктът вече е в производство и вие сте devops, на когото е казано да „настроите мониторинг“ - опитайте се да обясните на ръководството за какво съм написал всичко това.

Това е разширена версия на доклада на конференцията Saint Highload++.

Ако се интересувате от моите идеи и мисли за него и свързаните с него теми, тогава можете тук прочетете канала ????

Източник: www.habr.com