В чем заключается суть мониторинга
В чем заключается суть мониторинга
Статья 96. Мониторинг
1. Под мониторингом в целях настоящего Федерального закона понимается режим дистанционного государственного контроля (надзора), заключающийся в целенаправленном, постоянном (систематическом, регулярном, непрерывном), опосредованном получении и анализе информации о деятельности граждан и организаций, об объектах контроля с использованием систем (методов) дистанционного контроля, в том числе с применением специальных технических средств, имеющих функции фотосъемки, аудио- и видеозаписи, измерения, должностными лицами контрольного (надзорного) органа в целях предотвращения причинения вреда (ущерба) охраняемым законом ценностям.
2. Мониторинг основан на добровольном участии контролируемых лиц и осуществляется в случаях, установленных положением о виде контроля, по заявлению контролируемого лица на условиях соглашения между контролируемым лицом и контрольным (надзорным) органом.
3. Требования, которым должно соответствовать контролируемое лицо для осуществления мониторинга, устанавливаются положением о виде контроля.
4. Порядок организации и осуществления мониторинга устанавливается положением о виде контроля, соглашением между контрольным (надзорным) органом и контролируемым лицом.
5. Положение о виде контроля регулирует порядок подключения контролируемого лица (объекта) к автоматизированным информационным системам сбора и обработки данных, работающим в автоматическом режиме, специальным техническим средствам, имеющим функции фотосъемки, аудио- и видеозаписи, измерения, иным средствам сбора или фиксации информации, порядок доступа к указанным информационным системам и иным средствам сбора или фиксации информации, порядок обмена документами и иной информацией, а также характеристики автоматизированных информационных систем сбора и обработки данных, средств сбора или фиксации информации, места их установки, их количество, требования к необходимому программному обеспечению и при необходимости иные условия.
6. Форма соглашения о мониторинге утверждается контрольным (надзорным) органом и не может предусматривать преимущества для отдельных контролируемых лиц или оказание предпочтения отдельным контролируемым лицам.
7. Техническое оснащение и сопровождение мониторинга на объектах контролируемого лица производятся за счет контролируемого лица, если иное не установлено положением о виде контроля или соглашением о мониторинге.
8. Мониторинг осуществляется на основании решения контрольного (надзорного) органа, выпускаемого по результатам проведения оценки соответствия контролируемого лица требованиям, предъявляемым к нему для осуществления мониторинга, технической готовности контролируемого лица и контрольного (надзорного) органа к информационному взаимодействию в рамках мониторинга и заключения соглашения о мониторинге.
9. Соглашением о мониторинге между контролируемым лицом и контрольным (надзорным) органом может предусматриваться срок осуществления мониторинга, который не может быть менее одного года.
10. Уполномоченное должностное лицо контрольного (надзорного) органа принимает решение о прекращении осуществления мониторинга в одном из следующих случаев:
1) выявление несоответствия контролируемого лица требованиям, предъявляемым к нему для осуществления мониторинга, в том числе к технической оснащенности и сопровождению мониторинга;
2) неисполнение контролируемым лицом положений соглашения о мониторинге между контролируемым лицом и контрольным (надзорным) органом;
3) подача контролируемым лицом заявления о прекращении осуществления мониторинга;
4) иные случаи, установленные положением о виде контроля.
11. Контрольный (надзорный) орган уведомляет контролируемое лицо о прекращении мониторинга в течение десяти дней со дня принятия решения о прекращении осуществления мониторинга.
12. Федеральным законом о виде контроля может быть предусмотрено осуществление обязательного мониторинга в отношении контролируемых лиц, соответствующих критериям, установленным федеральным законом о виде контроля.
13. Порядок организации и осуществления обязательного мониторинга устанавливается положением о виде контроля.
14. Техническое оснащение и сопровождение обязательного мониторинга производятся за счет средств соответствующего бюджета бюджетной системы Российской Федерации, если иное не установлено федеральным законом о виде контроля.
15. Обязательный мониторинг осуществляется без ограничения срока его проведения.
16. Контролируемые лица, в отношении которых осуществляется обязательный мониторинг, освобождаются от плановых контрольных (надзорных) мероприятий в отношении соблюдения обязательных требований, являющихся предметом такого мониторинга.
17. В случае получения в ходе мониторинга, в том числе обязательного мониторинга, сведений о фактах нарушения обязательных требований контрольный (надзорный) орган принимает решения в соответствии с частью 2 статьи 90 настоящего Федерального закона.
Организация системы мониторинга
Мониторинг — это главное, что есть у админа. Админы нужны для мониторинга, а мониторинг нужен для админов.
За последние несколько лет поменялась сама парадигма мониторинга. Новая эра уже наступила, и если сейчас вы мониторите инфраструктуру как набор серверов — вы не мониторите почти ничего. Потому что теперь «инфраструктура» — это многоуровневая архитектура, и для мониторинга каждого уровня есть свои инструменты.
Кроме проблем типа «упал сервер», «надо заменить винт в рейде», теперь надо понимать проблемы уровня приложения и уровня бизнеса: «взаимодействие с микросервисом таким-то замедлилось», «в очереди слишком мало сообщений для текущего времени», «время выполнения запросов к бд в приложении растет, запросы — такие-то».
У нас на поддержке около пяти тысяч серверов, в самых разных конфигурациях: от систем из трех серверов с кастомными докеровскими сетками, до больших проектов с сотнями серверов в Kubernetes. И за всем этим надо как-то следить, вовремя понимать, что что-то сломалось и быстро чинить. Для этого надо понять что такое мониторинг, как он строится в современных реалиях, как его проектировать и что он должен делать. Об этом и хотелось бы рассказать.
Как было раньше
Лет десять назад мониторинг был гораздо проще, чем сейчас. Впрочем, и приложения были попроще.
Мониторились, в основном, системные показатели: CPU, память, диски, сеть. Этого вполне хватало, потому что там крутилось одно приложение на php, и ничего больше не использовалось. Проблема в том, что по таким показателям обычно мало что можно сказать. Либо работает, либо нет. Что именно происходит с самим приложением, выше уровня системных показателей понять сложно.
Если проблема была на уровне приложения (не просто “сайт не работает”, а “сайт работает, но что-то не так”), то клиент сам писал или звонил, сообщал, что есть такая-то проблема, мы шли и разбирались, потому что сами мы такие проблемы заметить не могли.
Как сейчас
Сейчас совсем другие системы: с масштабированием, с автоскейлингом, микросервисы, докеры. Системы стали динамичными. Часто никто толком не знает, как именно все работает, на скольких серверах, как именно оно развернуто. Оно живет своей жизнью. Иногда даже неизвестно, что и где запущено (если это Kubernetes, например).
Усложнение самих систем, конечно, повлекло за собой большее количество возможных проблем. Появились метрики приложений, количество запущенных тредов у Java application, частота garbage collector pauses, количество событий в очереди. Очень важно, чтобы мониторинг также следил за масштабированием систем. Допустим, у вас Kubernetes HPA. Надо понимать, сколько запущено подов, и с каждого запущенного пода должны идти метрики в систему мониторинга приложения, в apm.
Все это нужно мониторить, потому что все это отражается на работе системы.
И сами проблемы стали менее очевидными.
Условно, проблемы можно поделить на две большие группы:
Проблемы первого рода – не работает основная, “пользовательская функциональность”.
Проблемы второго рода – что-то работает не так, как должно, и может куда-то не туда привести.
То есть теперь надо мониторить не только дискретное “работает/не работает”, а гораздо больше градаций. Что, в свою очередь, позволяет ловить проблему до того, как все рухнет.
Кроме того, теперь надо следить и за бизнес-показателями. Бизнес захотел иметь графики о деньгах, о том как часто идут заказы, сколько времени прошло с последнего заказа и так далее — это теперь тоже задача мониторинга.
Правильный мониторинг
Проектирование и вообще
Представление о том, что именно надо будет мониторить, должно быть заложено в момент разработки приложения и архитектуры, и речь даже не столько про серверную архитектуру, сколько про архитектуру приложения в целом.
Разработчики/архитекторы должны понимать какие части системы критичны для функционирования проекта и бизнеса, и заранее думать о том, что их работоспобность надо проверять.
Мониторинг должен быть удобным для админа, и давать представление о том, что происходит. Цель мониторинга – вовремя получить оповещение, по графикам быстро понять, что именно происходит и что именно нужно чинить.
Метрики и оповещения (алерты)
Алерты должны быть максимально понятными: админ, получив алерт, даже если он не знаком с системой, должен понять, о чем этот алерт, в какую документацию смотреть, или хотя бы кому позвонить. Должны быть четкие инструкции, что именно нужно делать, и как именно решать проблему.
Когда возникает проблема, очень хочется понять, из-за чего она возникла. Получая алерт о том, что у вас не работает приложение, вам очень хотелось бы знать, какие еще смежные системы ведут себя не так, какие еще есть отклонения от нормы. Должны быть понятные графики, собранные в дашборды, из которых сразу будет видно, где отклонение.
Для этого надо точно понимать, что нормально, а что не нормально. То есть должна быть достаточная историческая справка о состоянии системы. Задача заключается в том, чтобы покрыть алертами все возможные отклонения от нормы.
Когда админ получает алерт, он либо должен знать что с ним делать, либо кого спросить. Должна быть инструкция как именно нужно реагировать, и ее надо регулярно обновлять. Если у вас все работает через систему оркестрирования, то, наверное, у вас все хорошо, если все изменения происходят только через нее, в том числе и мониторинг. Система оркестрирования позволяет адекватно следить за актуальностью мониторинга.
Мониторинг должен расширяться после каждой аварии — если внезапно возникла какая-то проблема, которая проскочила мимо мониторинга, то, очевидно, надо замониторить эту ситуацию, чтобы в следующий раз проблема не была внезапной.
Бизнес-показатели
Полезно мониторить время с последней продажи, количество продаж за период. Если выложили релиз, то что изменилось: есть ли просадки по бизнес-показателям? На это отвечает, конечно, A/B тестирование, но графики тоже хотелось бы иметь. И надо мониторить действия конечного пользователя: писать скрипты на phantomjs, которые повторяют покупку, проходят по всем этапам основного бизнес-процесса.
Также вам, наверное, интересно знать, работает ли сервис логистики, или не свалился ли в очередной раз IpGeoBase. (Комментарий редактора: IpGeoBase — сервис, который использует большое число интернет-магазинов на 1С-Битрикс для определения местоположения пользователя. Чаще всего это делается непосредственно в коде загрузки страницы, и когда падает IpGeoBase — у нас перестают отвечать десятки сайтов. Кто-нибудь пожалуйста, скажите программистам, что это надо обрабатывать и делать таймаут, и кто-нибудь — пожалуйста попросите IpGeoBase не падать).
Нужно понимать, зависит ли просадка по бизнес-показателям от вашей системы, или от внешней.
Мониторинг мониторинга
Сам мониторинг тоже должен хоть как-то мониториться. Должен быть какой-то внешний кастомный скрипт, который будет проверять, что мониторинг работает нормально. Никому не хочется проснуться от звонка, потому что ваша система мониторинга упала вместе со всем дата-центром, и вам об этом никто не сказал.
Основные инструменты
В современных системах, которые масштабируются, у вас наверняка используется Prometheus, потому что аналогов в принципе нет. Для того, чтобы просматривать удобные графики от Prometheus нужна Grafana, потому что в Prometheus графики так себе. Нужен также какой-то APM. Либо это самописная система на Open Trace, jaeger и или что-то подобное. Но это редко кто делает. В основном используется либо New Relic, либо специфичные системы для стеков, типа Dripstat. Если у вас не одна система мониторинга, не один Zabbix, вам еще нужно понимать, как собирать эти метрики, и как раздавать алерты; кого оповещать, кого поднимать, в каком порядке, к кому какой алерт относится, и что с ним вообще делать.
Zabbix — не самая удобная система. Есть проблемы с кастомными метриками, особенно, если система масштабируется, и вам нужно определить роли. И хотя можно строить очень кастомные графики, алерты и дашборды, все это не очень неудобно и нединамично. Это статичная система мониторинга.
Prometheus — отличное решение для сборки огромного количества метрик. У него примерно те же возможности, что у Zabbix по кастомным алертам. Можно выводить графики и строить алерты по любым диким сочетаниям нескольких параметров. И это все очень здорово, но очень неудобно смотреть, поэтому к нему добавляется Grafana. Grafana очень красивая. Но сама по себе не очень помогает для мониторинга систем. Зато по ней удобно все читать. Лучше графиков, наверное, и нет.
ELK и Graylog — для сбора логов по событиям в приложении. Может быть полезно для разработчиков, но для подробной аналитики обычно не достаточно.
New Relic — APM, тоже полезный для разработчиков. Есть возможность понять, когда у вас в приложении прямо сейчас что-то идет не так. Понятно, какие из внешних сервисов не очень хорошо работают, или какая из баз медленно отвечает, либо какое системное взаимодействие просаживается.
Свой APM — если вы написали свою систему на Open Tracing, zipkin или jaeger, то, наверное, вы знаете, как именно это должно работать, и что именно, и в какой части кода идет не так. New Relic тоже позволяет это понять, но это не всегда удобно.
Заключение
О том какие показатели надо мониторить лучше думать в время проектирования системы, заранее подумать о том какие части системы критичны для ее работы и о том, как проверять их работу.
Алертов не должно быть слишком много, алерты должны быть актуальными. Должно быть сразу понятно, что сломалось и как это чинить.
Чтобы правильно замониторить бизнес-показатели, надо понять как устроены бизнес процессы, что нужно вашим аналитикам, хватает ли инструментов чтобы замерить нужные показатели, и как быстро можно узнать, если что-то пойдет не так.
В следующем посте мы расскажем как правильно спланировать мониторинг современной инфраструктуры, на всех уровнях: на уровнях системы, приложений и бизнеса.
Что такое мониторинг и его уровни
Поговорим о том, какие уровни мониторинга бывают и что стоит измерять и анализировать в IT-проектах.
Зачем нужен мониторинг и что это такое
Случается, что серверы падают и программы ломаются. Это неизбежно. Случайный баг, скачок напряжения в сети, сбои в подаче электричества — всё это может вызывать поломки.
Кроме того, помимо очевидных проблем, могут быть и куда менее очевидные. Например, менеджеры по продукту приняли плохое решение, реализовали плохую фичу и из-за нового релиза упала выручка. Технически код хорошо работает, серверы в порядке — но бизнес несет убытки.
Начнем снизу: мониторинг оборудования
Что бы вы ни запускали — у вас всё равно будут серверы в дата-центре, а у них есть определенные параметры производительности. Эти показатели надо мониторить на каждом сервере, обслуживающем ваших клиентов:
Список параметров вполне очевиден. Мониторинг этих значений позволяет диагностировать большую пачку неприятных ситуаций, которые могут привести к полному или частичному коллапсу инфраструктуры.
Для анализа поведения серверов в самом простом виде можно использовать штатные средства контроля по типу htop. Более гибкое и масштабируемое решение — Zabbix — он уже умеет анализировать основные параметры целого кластера серверов и собирать их в одной панели. Такое решение требует настройки со стороны квалифицированного администратора.
Поднимаемся выше: мониторинг состояния приложений
Допустим, мониторинг серверов у нас есть и они выглядят адекватно. Памяти много, нагрузка на процессор — незначительная. Наверное, всё хорошо организовано, клиентов немного, всё работает как часы? Может быть. Или всё упало, программы не запущены, клиенты не могут попасть на сервер и выполнить запросы? Тоже может быть.
Какой из вариантов правильный — подскажут метрики приложений.
У любого приложения должны быть параметры, по которым разработчики и администраторы понимают, что программа работает и в ней что-то делается. У каждой программы эти параметры свои, но вот несколько примеров, которые позволят понять, какие метрики нужно придумать для приложения:
У вас в системе 100 активных пользователей, они генерируют 1 000 запросов в минуту и у них случается 1 ошибка в час? Допустим, что всё хорошо. У вас в системе 3 активных пользователя, они генерируют 10 000 запросов в минуту и ловят 5 000 ошибок? Наверное, стоит начать беспокоиться. Даже если метрики нагрузки на процессор и диски в порядке.
Для мониторинга на этом уровне подойдет специализированная СУБД — Prometheus, Graphite, InfluxDB. С установкой самой базы данных проблем не будет, а вот посчитать и пробросить нужные метрики в базу — для этого понадобятся усилия программистов.
Для удобства анализа ко всем этим базам лучше всего подключить Grafana — графический инструмент для отображения статистики и метрик.
Есть еще специфические системы отлова ошибок в коде — они могут вовремя оповестить программистов о сбойной ситуации. Иногда этого вполне достаточно для базовой диагностики проблем. Хороший пример такой системы — Sentry.
Третий уровень: мониторинг бизнес-метрик
Конечная цель любой программы — решать чьи-то проблемы и получать за это деньги. Это значит, что для управленцев нужны метрики, которые расскажут:
Список метрик, которые нужны бизнесу, велик и зависит от конкретного проекта и индустрии. Лучше всего вам помогут разобраться с правильными параметрами менеджеры продукта.
Минимально здесь можно обойтись Google Analytics — базовые конверсии и переходы можно смотреть в готовых системах анализа пользовательского поведения. Более глубокое понимание ситуации потребует четкой и слаженной работы администраторов, программистов и ребят из отдела аналитики — они смогут правильно реализовать и посчитать тонкие поведенческие аспекты. Например, зависимость выручки от A/B-тестов на бэкенде.
Мониторинг — что это такое
Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Периодически возникает желание объяснить те термины, что я и многие другие постоянно используют в своих статьях в интернете или в устной речи. До этого мы уже поговорили про гайды, про геймеров, про парадигмы, а так же коснулись темы троллинга, хейтерства и перфекционизма.
Сегодня у нас на очереди мониторинг. Что это такое? Зачем он нужен? Что можно и нужно мониторить? Кто этим занимается? Да и зачем вообще все это нужно? Вот такой вот краткий план для данной публикации. Поехали.
Что означает слово мониторинг
Сразу стоит оговориться, что слово это очень популярно и широко распространено. Используется оно чуть ли не во всех жизненных аспектах и потому интерес к нему довольно высок. Образовано оно, как ни удивительно, от английского слова monitoring, что в переводе означает: контролировать, проверять, наблюдать.
Собственно, на этом статью можно было бы и закончить, ибо ключевые слова, позволяющие понять что такое мониторинг, уже прозвучали — это контроль, наблюдение, проверка (периодическая или постоянная). Но все же я с вашего позволения продолжу и скажу хотя бы еще пару слов в пояснение сути, ну и примеры приведу для наглядности.
Если попробовать дать определение мониторингу другими словами, то это будет сбор информации. Причем собираться может все что угодно — данные по концентрации вредных веществ в атмосфере, финансовые показатели банков, информация проходящая в СМИ по какой-то тематике, доступность сайтов, значение текущих курсов валют (либо криптовалют) и т.д.
Самом собой, что мониторинг не ограничивается только сбором информации (накоплением данных). В его задачи так же входит их анализ или обработка, а зачастую так же принятие каких-то мер или действий по результатам этого анализа.
Например, Яндекс проводит мониторинг дорожной обстановки в Москве и других городах России, обрабатывает собранные данные и выдает «на гора» в виде карты пробок или предупреждений о затруднениях на дорогах. Информацию он собирает с помощью стационарных систем слежения и с помощью телефонов пользователей едущих в данный момент по дорогам страны.
Собираются данные о скорости движения машин владельцев телефонов, согласившихся передавать Яндексу такую информацию, и после обработки они выдаются в виде цветовой схемы в приложении «Яндекс Пробки», и в другие приложения с ним сотрудничающие. Этот процесс (сбора и обработки, т.е. мониторинга) идет постоянно, что и позволяет видеть реальную картину пробок практически в реальном времени.
Если вы живете в крупном городе, то наверняка в вашем подъезде ведется видеонаблюдение, которое тоже можно отнести к процессу мониторинга. Данные собираются на постоянной основе, а потом при необходимости могут послужить для прояснения моментов криминального и другого характера.
Мониторинг в примерах — какой он бывает
Наверняка вы слышали про финансовый мониторинг, когда центробанк отслеживает ключевые показатели банков, чтобы вовремя понять, что с каким-то из них начинают происходить неприятные вещи. Хотя, подобного вида наблюдения и проверки в финансовой сфере проводятся и на более низких уровнях — внутри банков, компаний и предприятий. Но суть та же — выявить признаки нестабильности, воровства или других негативных (или позитивных) тенденций.
Про экологический мониторинг я уже упоминал, но это не только наблюдение за количеством вредных веществ на улицах больших городов. Это и измерение температуры в разных уголках страны, и радиационный мониторинг, и наблюдение за направлением и силой ветра, за ростом количества мусора на свалках (полигонах), за выбросами крупных предприятий и мусоросжигательных заводов, и многое другое.
Мониторинг ведется практически во всех сферах жизнедеятельности — в образовательной, в культурной, в средствах массовой информации, в промышленности и сельском хозяйстве, в информационных средах (например, мониторинг общественного мнения), в сфере здравохранения и многом другом.
Почему это так важно? Зачем на это тратится столько времени и средств?
Ну, потому что это позволяет получить обратную связь и понять, что делается правильно, а что нужно менять.
Без этого невозможно будет четко отследить момент, когда нужно принимать срочные меры (например, мониторинг пожароопасной ситуации в периоды засухи), реагировать или просто выбрать лучшее среди имеющегося в данный момент выбора (например, мониторинг курсов криптовалют в обменниках или маршрут проезда с учетом пробок).
И еще большее значение мониторинг приобретает в эпоху цифровых технологий. Данных становится больше, анализировать их на глазок уже очень сложно, а значит становятся востребованы услуги тех, кто предлагает на аутсорсинге свои услуги по их сбору, упорядочиванию и представлению результата в удобоваримом виде.
Например, сервисы подобные Яндекс Маркет помогают вам сделать правильный выбор в том, что именно и где именно лучше купить. По сути, это вариант маркетингового мониторинга рынка на предмет лучшего предложения в сегменте и лучшего продавца (по цене и качеству обслуживания), опирающегося на отзывы пользователей (данные).
Так же примером могут служить сервисы мониторинга курса обменников, которые собирают данные по текущим курсам обмена с десятков, и даже сотен пунктов обмена, позволяя вам буквально за минуту выбрать самый выгодный для вас курс в более-менее надежном обменнике. Последнее опять же реализовано на сборе отзывов пользователей уже совершавших там обмены.
Если у вас уже есть свой сайт или вы только планируете его создать, то вам будет сложно обойтись без сервисов мониторинга доступности сайтов, которые смогут вас оперативно предупредить (сообщением на Емайл или СМС-кой на телефон) о том, что ваш сайт стал недоступен пользователям сети (возникли проблемы с хостингом, ваш сайт подвергся ддос-атаке или еще что-то случилось). Без постоянного мониторинга доступности вы об этом оперативно не узнаете и можете потерять позиции в поисковых системах.
Раз уж речь зашла про сайты, то при их продвижении вам может понадобиться сервис мониторинга позиций сайта в поисковых системах. У вас будут сотни и тысячи запросов, по которым желательно отслеживать позиции в выдаче Яндекса и Гугла, чтобы вовремя реагировать на их падение или рост (держать руку на пульсе). Профессиональные сеошники без этого просто жить не могут. Проверять же все это вручную практически не реально даже в краткосрочной перспективе
О будущем мониторинга
Очевидно, что различные мониторинги сейчас в тренде. Подобных сервисов и услуг, а так же компаний этим занимающихся будет становиться все больше и больше, ибо количество информации растет, а конкуренция повышается.
У нас капитализм, а значит нужно толкаться локтями, чтобы пробиться выше. Для того, чтобы тебя не затерли и в результате не оказаться на обочине, нужно всегда оперировать самыми свежими данными, а для этого нужно их мониторить, либо покупать эту информацию (отдавать на аутсорсинг) у тех, кто на этом подвязался зарабатывать.
В общем, скоро уже не будет тех, у кого это слово будет вызывать какие-либо вопросы и недоумения. Но пока будущее еще не наступило, надеюсь, что сей опус сослужил хоть кому-то добрую службу.
Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru
Эта статья относится к рубрикам:
Комментарии и отзывы (3)
Мониторинг по-русски — это и проверка и наблюдение, смотря в каком контексте оно употребляется.
Если в медицине, то это больше наблюдение, чем проверка. А вот если дело касается предприятия, то мониторинг — это скорее уже проверка. Допустим предприятию выделили деньги, и проводят мониторинг чтобы посмотреть что было сделано, куда были потрачены и т.п.
Почему у нас стало нормой использовать иностранные слова, если можно высказать свое мнение на русском. скоро придется со словарем ходить, чтобы понять о чем говорят окружающие.
Светлана: кто первый встал, того и тапки. Этот принцип действует везде.
Чтобы тебя понимали ты должен пользовать общепризнанной терминологией. А она идет к нам, в основном, из английского языка.
Если проанализировать, то еще до Вашего рождения в русском языке половина (или больше) слов были заимствованы.