>>3757
Обсервабилити (observability) и мониторинг имеют схожие цели, но концептуально и практически они различаются.
1. Мониторинг

Мониторинг — это процесс отслеживания заранее определённых метрик, логов и событий с целью выявления отклонений или проблем. Обычно в мониторинге:

Вы предопределяете метрики и логи, которые важно собирать.
Система настроена на оповещение о конкретных нарушениях или аномалиях (например, CPU выше 80% или доступность сервиса ниже 99%).
Это реактивный подход: вы узнаёте о проблеме, когда она уже произошла и соответствует заданным условиям.

2. Обсервабилити

Обсервабилити — это способность системы давать ответы на вопросы, которые вы не предвидели заранее. Это более широкая концепция, включающая не только сбор данных, но и их организацию, анализ и контекстуализацию. Основные отличия:

Неопределённость: Обсервабилити позволяет исследовать поведение системы в новых или неожиданных ситуациях (например, почему новая версия приложения вдруг замедлилась на некоторых запросах?).
Комплексность: Собираются три ключевых типа сигналов:
Метрики — количественные показатели (время отклика, ошибки).
Логи — текстовые записи событий и операций.
Трейсы — информация о прохождении запросов через распределённую систему.
Инструменты анализа: обсервабилити-платформы предоставляют средства для гибкого и интерактивного анализа (поиск корреляций, построение запросов, исследование зависимостей).
Проактивный подход: это помогает не только диагностировать проблемы, но и предотвращать их, анализируя слабые места до инцидентов.

3. Почему обсервабилити ≠ просто объединение?

Хотя обсервабилити использует метрики, логи и трейсы, ключевое отличие в цели и методах работы:

Обсервабилити делает упор на контекст и связь между данными, предоставляя инструменты для динамического исследования системы.
Это не просто сбор и визуализация данных, а создание платформы для поиска и объяснения любых системных аномалий.
Например, обсервабилити-системы (такие как Honeycomb, Datadog, или Grafana Tempo) помогают видеть, как и почему что-то происходит, связывая данные между разными уровнями системы.

4. Пример:

Мониторинг:

Если падает API, вы получите алерт: "Доступность ниже 99%".
Вы видите метрику, указывающую на проблему, но чтобы выяснить причину, нужно рыться в логах и трейсах вручную.

Обсервабилити:

Вы задаёте системе вопрос: "Почему задержка API возросла для запросов из региона X?"
Она покажет вам коррелирующие события, зависимости между сервисами, аномалии в трейсах и даже, возможно, причину проблемы.

5. Заключение

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

>>4824
Как AD, mikrotik и ip телефония относятся к devops? Или я тебя неправильно понял?

Devops это про ci/di, кубы, автоматизация и пайплайны, git (тут очевидный gitlab), IaC (очевидный terraform и andible), zabbix это ок, но я бы ещё добавил prometheus, само собой jenkins. Ещё почему-то все забывают про nosql, брокеры сообщений и балансировщики.

Можно добавить докер, линукс и сети, но, например, в моей компании девопсы вообще не трогают сети а работаю я в МЯСКОТ, так что в определенной мере это стандарт индустрии. Если видишь такое в требованиях, то это моветон и лучше скипнуть, так как противоречит самой философии devops ведь это именно про идеологию, а не какую-то конкретную специальность.

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

>>4808

>Хотя если ты сисадмин с опытом, то опыт котируется

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

>поэтому можно сразу на мидла откликаться.

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

>>4406

>3 год сосет бибу за 70к в ДС1

В ДС на начальных позициях в IT таких зп нет. Тем более с опытом в 2 года. Ты либо что-то не договариваешь, либо твой друг не совсем адекватен.

Мимо проходил, попался ваш тред. Выглядит как эхо-камера админов из ООО ПромСтройБетон без негатива . Если метите в девопсы, то учите хотя бы актуальный стек, если в тестеры, то зубрите теорию тестирования, набивайте руку на чек-листах, тест-кейсах и отчетах о тестировании, дальше в зависимости от того направления, куда вы хотите попасть. На количество откликов даже не смотрите, внутренние процессы HR в крупных компаниях позволяют поработать с кандидатом, который был 3001-ый по отклику. Могу ответить на вопросы по существу, 280к, AQA, финтех.

>>7721
Для прописывания базовой станции (BS) на RNC (Radio Network Controller) и BSC (Base Station Controller) необходимо настроить соответствующие параметры и компоненты на каждом из контроллеров. Оба этих устройства управляют базовыми станциями, но с некоторыми различиями в архитектуре.

### 1. RNC (Radio Network Controller)

RNC — это часть сети, управляющая радиочастотными ресурсами и управлением соединениями в WCDMA (UMTS). В нем управляются несколько Node B (базовых станций).

Шаги для настройки базы станции на RNC:

1. Подключение Node B к RNC:
- На RNC необходимо создать объект для базовой станции Node B.
- Укажите параметры подключения (например, IP-адреса, идентификаторы и протоколы для связи между RNC и Node B).

2. Конфигурация и активация базовой станции:
- В настройках RNC укажите параметры базовой станции, такие как:
- Идентификатор Node B.
- Каналы и частоты.
- Ресурсы для передачи и приема.
- Параметры обработки сигналов.

3. Конфигурация каналов связи:
- Настройте каналы управления и передачи для базовой станции.
- Укажите параметры для голосовых и данных-соединений.

4. Подключение к внешним сетям (например, к SGSN):
- Подключите RNC к системе управления мобильной сетью (например, к SGSN), чтобы передавать данные о пользователях и управлять состоянием соединений.

5. Тестирование:
- Проверьте состояние базовой станции в сети, используя диагностические команды и мониторинг.

### 2. BSC (Base Station Controller)

BSC — это контроллер, который управляет множеством базовых станций в GSM-сетях. Он координирует работу базовых станций и управляет ресурсами связи.

Шаги для настройки базы станции на BSC:

1. Создание связи между BSC и базовой станцией:
- Для каждой базовой станции создайте соответствующий объект в конфигурации BSC.
- Укажите параметры связи между BSC и базовой станцией (например, каналы управления, IP-адреса и т. д.).

2. Настройка ресурсов базовой станции:
- Конфигурируйте каналы, на которых будет работать базовая станция (например, каналы для голосовых вызовов и передачи данных).
- Укажите параметры для обеспечения совместимости с другими элементами сети (например, с мобильными телефонами).

3. Подключение к другим компонентам сети:
- Настройте связи между BSC и другими компонентами сети, такими как MSC (Mobile Switching Center), GGSN (Gateway GPRS Support Node), SGSN и другими элементами инфраструктуры.

4. Активация и мониторинг:
- Проверьте правильность работы базовых станций через интерфейсы мониторинга.
- Убедитесь, что каналы и соединения активированы корректно.

5. Тестирование:
- Проведите тесты для проверки работы базовых станций, включая проверку качества сигнала и корректности связи.

### Заключение

Процесс прописывания базовой станции зависит от типа сети (UMTS для RNC или GSM для BSC) и от конкретного оборудования. Важно соблюдать порядок настройки и правильно указывать параметры подключения для успешной работы.

>>7749
В технической переписке на форуме специалистов недопустимо использовать не отредактированные ответы от нейронной сети по нескольким причинам:

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

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

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

Технические ошибки и лакуны: Нейронные сети могут не всегда следовать точным стандартам и правилам технической дисциплины. Например, могут быть допущены ошибки в коде, неправильные рекомендации по проектированию или некорректные математические выкладки.

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

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

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