Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Я хочу получать рассылки с лучшими постами за неделю
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
Создавая аккаунт, я соглашаюсь с правилами Пикабу и даю согласие на обработку персональных данных.
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam
Пикабу Игры +1000 бесплатных онлайн игр
Классический арканоид для любителей ретро-игр. Защитите космический корабль с Печенькой (и не только) на борту, проходя уровни в арканоиде.

Арканоид Пикабу

Арканоид, Аркады, Веселая

Играть

Топ прошлой недели

  • AlexKud AlexKud 38 постов
  • SergeyKorsun SergeyKorsun 12 постов
  • SupportHuaport SupportHuaport 5 постов
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

Нажимая кнопку «Подписаться на рассылку», я соглашаюсь с Правилами Пикабу и даю согласие на обработку персональных данных.

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Помощь Кодекс Пикабу Команда Пикабу Моб. приложение
Правила соцсети О рекомендациях О компании
Промокоды Биг Гик Промокоды Lamoda Промокоды МВидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня

DevOps

С этим тегом используют

IT IT юмор Программирование Linux Программист Юмор Сисадмин Все
243 поста сначала свежее
12
contentfactory
contentfactory
15 дней назад

Прогресс⁠⁠

Прогресс
Юмор X (Twitter) Скриншот Брак (супружество) DevOps Сисадмин
3
17
aidaho6
aidaho6
17 дней назад
GNU/Linux

Улучшения в RMON: расширенный Ping, группировка алертов и трассировка через MTR⁠⁠

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

Рассказываем, какие улучшения появились в RMON.

Улучшения в RMON: расширенный Ping, группировка алертов и трассировка через MTR IT, Linux, Сайт, Мониторинг, DevOps, Системное администрирование, Длиннопост

Ping стал умнее

Раньше проверка ping в RMON отправляла один пакет — это было достаточно для грубой оценки, но плохо отражало реальное состояние канала. Теперь всё иначе:

  • Можно указать количество ICMP-пакетов в настройках проверки.

  • Система собирает и отображает:

    • min RTT

    • max RTT

    • avg

    • mean

Это особенно полезно, если канал нестабилен: одиночный ping может случайно показать “всё хорошо”, хотя на деле теряются пакеты или резко плавает задержка.

| Возможность | SmokePing | RMON |

|-----------------------------|----------------|---------------------------|

| Графики RTT и потерь | ✅ Да | ✅ Да |

| Группировка алертов | ❌ Нет | ✅ Да |

| Настраиваемое кол-во пакетов| ✅ Частично | ✅ Да |

| Интерактивный веб-интерфейс | ❌ (CGI) | ✅ Современный UI |

| MTR из разных регионов | ❌ Нет | ✅ Да |

| Проверки из нескольких точек| ❌ (1 сервер) | ✅ Геораспределённые агенты |

| Telegram/Slack уведомления | Только через внешние скрипты | ✅ Встроено |

| API | ❌ Ограничен | ✅ Полноценный REST API |

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

RMON же изначально создавался с упором на:

  • простую установку;

  • удобный интерфейс;

  • встроенные нотификации и API;

  • и главное — распределённый мониторинг из разных географий.

Группировка алертов

Пользователи с несколькими агентами в разных регионах сталкивались с таким сценарием:

"Падает один хост — и мы получаем 5+ одинаковых алертов от каждого региона".

Теперь алерты по одному хосту автоматически агрегируются:

  • Вы получаете единое уведомление со списком всех регионов, где обнаружена проблема.

  • Упрощается логирование, снижается "шум" в системах алертинга (Telegram, Slack и т.п.)

MTR на месте

Мы добавили возможность запускать MTR (traceroute с расширенной статистикой) из конкретного региона:

Улучшения в RMON: расширенный Ping, группировка алертов и трассировка через MTR IT, Linux, Сайт, Мониторинг, DevOps, Системное администрирование, Длиннопост
  • Прямо из веб-интерфейса или API

  • Можно быстро проверить маршрут от нужного агента до целевого хоста

Это особенно удобно при отладке проблем между регионами, в CDN, или при работе с провайдером.


Что дальше

Мы продолжаем развивать RMON как инструмент для распределённого мониторинга, ориентированный на:

  • телеметрию от агентов из разных регионов;

  • гибкую конфигурацию проверок;

  • удобную интеграцию с Telegram, Slack, Prometheus, Zabbix и другими системами.

Если вы хотите точно знать, где и когда у вас реально деградирует сеть — попробуйте RMON: https://rmon.io

Показать полностью 1
[моё] IT Linux Сайт Мониторинг DevOps Системное администрирование Длиннопост
16
2343
stavropol
stavropol
1 месяц назад
IT-юмор

Это вам не это!⁠⁠

Это вам не это! IT юмор, IT, DevOps, Взлом, Хакеры, Фильм ДМБ, Telegram (ссылка), Скриншот, Сарказм, Мемы

Может бахнем айти юмора?

IT юмор IT DevOps Взлом Хакеры Фильм ДМБ Telegram (ссылка) Скриншот Сарказм Мемы
76
Партнёрский материал Реклама
specials
specials

Считаете себя киноманом 80 LVL?⁠⁠

Залетайте проверить память и сообразительность → Будет интересно

Киногерои Тест Текст
12
NaruCodex
NaruCodex
1 месяц назад
Программисты шутят

Протокол вскрытия неопознанного распределенного монолита⁠⁠

Протокол вскрытия неопознанного распределенного монолита IT юмор, Программирование, Юмор, Разработка, Код, Длиннопост, Баг, Легаси, DevOps, Монолит, Микросервисы

[Начало аудиозаписи (бодрый голос, с нотками цинизма и усталости)]

Протокол вскрытия № 666-IT/2025. Дата: 17 мая 2025 года. Время: 05:30.

- Я, ведущий DevOps-патологоанатом Сисадминов А.А., приступаю к патологоанатомическому исследованию неопознанного распределенного монолита, поступившего из ООО "Светлое Будущее" после фатального падения системы, зафиксированного 16 мая 2025 в 23:58 по московскому времени.

- Присутствуют: я, младший специалист Логинов П.Р., стажер Архитекторова Н.Ю.

Протокол вскрытия неопознанного распределенного монолита IT юмор, Программирование, Юмор, Разработка, Код, Длиннопост, Баг, Легаси, DevOps, Монолит, Микросервисы

- Итак, начнем. Внешний осмотр. Перед нами типичный корпоративный монолит — старожил цифрового мира. Судя по следам от PHP 5.3 в виде комментариев к коду, датированным 2011 годом, ему не меньше 14 лет. Внушительный возраст для любой системы в кровавом Энтерпрайзе, не находите, Логинов?

- Да, это почти живой мамонт!

- Отмечаю критическую анемию документации. В репозитории — одинокий README.md от 2012 года с гордой надписью "TODO: написать документацию".

- Так, что у нас тут… Kubernetes? О, да! Модный, молодежный. Оркестрация уровня «дирижер в запое». Поды висят в CrashLoopBackOff чаще, чем разработчики этого чуда видят кофейный аппарт. Логи… о, мда, логи! «Something went wrong», «Error: null», «PANIC: KERNEL PANIC (not really, just kidding, or am I?)». Креативненько, ничего Логинов, возьмите образцы на анализ.

- Первичный осмотр выявляет множественные очаги копипасты. Особенно вопиющий случай — модуль авторизации. Код проверки прав доступа размножен 47 раз с минимальными правками. Это уже не просто технический долг, это цирк абсурда ролевых моделей!

- Вижу следы восьми разных фреймворков, некоторые из которых не совместимы. Это мне напоминает "инновационный борщ, тёщи, приправленный усушенными котлетками и жаренными пельменями", брр. А вот это что? Закомментированный кусок кода с пометкой «// Игорь, это не трогай, я сам не знаю, как оно работает, но без него все падает!!!11». Игорь, если ты это слышишь, ты был не прав – оно и с ним упало. Из мешанины использованных языков программирования в разных модулях, можно предположить, что разработчики стремились изобрести свой высокоуровневый Brainf**k, совсем чуточку не успели.

Протокол вскрытия неопознанного распределенного монолита IT юмор, Программирование, Юмор, Разработка, Код, Длиннопост, Баг, Легаси, DevOps, Монолит, Микросервисы

- Ага, вот и причина непосредственного отказа. Один из «сервисов» решил, что ему мало 128 Гб оперативной памяти и попытался сожрать еще столько же из свопа. Классический OOM Killer пришел и сделал свою работу. Но это, так сказать, орудие убийства. Причина отказа куда глубже.

[идет продолжительная работа]

- Отказ наступила из-за необратимых изменений кода, навороченных за 13 лет разными разработчиками с их "уникальным видением". Рекомендации родственникам: кремация кодовой базы и старт с нуля. Пациент был нежизнеспособен с момента зачатия идеи в воспаленном мозгу тимлида.

- Ладно, хватит лирики. Пойду оформлять официальный протокол, Логинов, мне нужны результаты анализов. Эти бюрократы из «МинЦифЗдрава» требуют всё по форме.

[Щелчок выключения диктофона]


УТВЕРЖДАЮ

Заместитель начальника Отдела цифровой патологии и реанимации информационных систем

И.И. Кибернетиков

«18» мая 2025 г.

ПРОТОКОЛ № 666-IT/2025 патологоанатомического вскрытия информационной системы

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

Дата и время поступления системы: 17.05.2025, 04:48 (MSK)

Идентификатор «умершего»: Проект «Прорыв-2012», версия - неизвестная.

Возраст (время эксплуатации до фатального сбоя): 14 лет, 3 месяца, 2 дня (в режиме «постоянно падает, но мы поднимаем»).

Дата и время «полного отказа»: 16.05.2025, 23:58 (MSK)

Основной «клинический» диагноз (предварительное заключение службы эксплуатации): «Все сломалось, ничего не работает, пользователи в ярости, не могут закрыть спринт».

Дата и время вскрытия: 17.05.2025, 05:30 (MSK)

Вскрытие производил: Ведущий DevOps-патологоанатом Сисадминов А.А.

Присутствовали: Младший специалист по цифровой некроскопии Логинов П.Р., стажер Архитекторова Н.Ю. (сбежала через 15 минут с криком «О боже! Да я лучше бухгалтерию, буду переводить на метод ФИФО!»).

НАРУЖНЫЙ ОСМОТР СИСТЕМЫ: «Кожные пользовательские интерфейсы» недоступны, ответ сервера HTTP 503 (Service Unavailable) на всех эндпоинтах. «Трупные ошибки в логах» обильные, хаотично распределены по всем компонентам системы. «Трупное зависание процессов» наблюдается в 6 из 8 основных модулей. Сопроводительная документация-анамнез разработки фрагментарна, содержит ненормативную лексику и наскальные рисунки, не относящиеся к делу. Архитектурная схема представлена в виде эскиза на длинном бумажном чеке из КБ, вызывает сомнения.

ВНУТРЕННЕЕ ИССЛЕДОВАНИЕ СЕРВИСОВ И ПОЛОСТЕЙ СИСТЕМЫ:

  1. «Центральная нервная система Оркестратор Kubernetes»: Версия 1.25.х (устаревшая). Множественные Pod'ы в состоянии CrashLoopBackOff и ImagePullBackOff. Обнаружены некорректно сконфигурированные readiness и liveness пробы, приводящие к преждевременному «умерщвлению» работоспособных экземпляров. Конфигурационные файлы содержат критические данные в открытом виде.

  2. «Сердечно-сетевая система межсервисного взаимодействие»: Топология сети избыточно сложная, напоминает «Гордиев узел». Задержки при взаимодействии между «микросервисами» достигают нескольких десятков секунд. Обнаружены следы использования самописного протокола поверх HTTP/1.1 для передачи бинарных данных, что приводило к их регулярной закупорке каналов связи. «Микросервисы» по факту являются монолитными приложениями, упакованными в Docker-контейнеры, с высоким уровнем связанности (tight coupling).

  3. «Дыхательная API Gateway система»: API Gateway перегружен из-за отсутствия кэширования и неоптимальных запросов от фронтенда. Модуль «AuthService» демонстрирует признаки «гипертрофии» (размер Docker-образа 3 Гб) и «кислородного голодания» (регулярные OOM Killed). Обнаружены многочисленные хардкод-адреса зависимых сервисов.

  4. «Пищеварительная база данных»: Основная СУБД PostgreSQL – горизонтально шардированная. Структура БД ненормализована, наименования таблиц и полей не соответствуют общепринятым стандартам (например, tbl_prod_final_v2_important). Индексы на часто запрашиваемых полях отсутствуют. Обнаружены следы «несварения» данных (неконсистентность) между репликами. Обнаружена метастаза в виде документно-ориентированной MongoDB из одной коллекции, c полу структурированными данными.

  5. «Опорно-двигательная кодовая база»: Код написан на смеси Python, Go и Node.js (в рамках одного «микросервиса»), в наличии остаточные следы PHP. Присутствуют многочисленные «велосипеды» (самописные решения для стандартных задач). Уровень покрытия тестами – предположительно, менее 5%. Обнаружены закомментированные участки кода с пометками «не трогать, магия» и «костыль, убрать перед релизом».

ПАТОЛОГОАНАТОМИЧЕСКИЙ ДИАГНОЗ:

  • Основное «заболевание»: Острая декомпенсированная архитектурная недостаточность, развившаяся на фоне тотального игнорирования принципов проектирования распределенных систем и DevOps-практик. Тип: «Распределенный Монолит с полиорганной дисфункцией микросервисов».

  • Осложнения: Синдром каскадного отказа модулей. Терминальная стадия технического долга. Критическая зависимость от «магического кода Игоря», о чем свидетельствуют множественные коммиты. Фатальные уязвимости безопасности.

  • Сопутствующие «заболевания»: Хроническое отсутствие автоматизированного тестирования. Дефицит компетентной документации. Синдром «Неприятия чужой разработки» (NIH) в тяжелой форме.

ЗАКЛЮЧЕНИЕ О ПРИЧИНЕ «ОТКАЗА» СИСТЕМЫ: «Отказ» информационной системы «Прорыв-2012» наступила в результате совокупности критических архитектурных просчетов, некомпетентной реализации, отсутствия контроля качества и пренебрежения базовыми принципами разработки и эксплуатации ПО. Непосредственной причиной остановки функционирования явился отказ модуля «AuthService» вследствие исчерпания выделенных ресурсов памяти (OOM Killer), что вызвало цепную реакцию отказа зависимых компонентов. Система стала нежизнеспособна в долгосрочной (и, как оказалось, краткосрочной) перспективе.

РЕКОМЕНДАЦИИ:

  1. Признать проект «Прорыв-2012» полностью несостоятельным.

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

  3. Останки системы (репозитории, артефакты сборки, конфигурации) архивировать с пометкой «Крайне токсично. Не реанимировать!».

  4. Команде разработки в полном составе пройти курсы повышения квалификации по темам: «Основы архитектуры ПО», «DevOps для чайников», «Тестирование – это не больно».

  5. При планировании аналогичных проектов в будущем закладывать бюджет на привлечение внешних ИТ-архитекторов и независимых стейколдеров.

Ведущий DevOps-патологоанатом

___________________ Сисадминов А.А.

М.П. (Отдела Цифровой Патологии)

Показать полностью 3
[моё] IT юмор Программирование Юмор Разработка Код Длиннопост Баг Легаси DevOps Монолит Микросервисы
0
9
AppFox
AppFox
1 месяц назад

Kubernetes в продакшене: основные понятия и вопросы на собеседовании⁠⁠

Меня зовут Александр, я CTO компании AppFox. Мы более 10 лет занимаемся заказной разработкой и также имеем собственные продукты.

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

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Что такое Kubernetes простыми словами?

Разберем на примере интернет-магазина с тремя серверами:

  1. Сервер №1 – основной (принимает заказы).

  2. Сервер №2 – база данных (хранит товары и пользователей).

  3. Сервер №3 – бекенд для API (обрабатывает платежи).

Проблема:

  • В Чёрную пятницу приходит в 10 раз больше покупателей. В результате, сервера №1 и №3 падают от нагрузки, магазин "висит".

  • Сервер №2 (база данных) ломается, а все заказы теряются.

  • Чтобы добавить новые сервера, админ вручную копирует настройки, что занимает часы.

Решение при помощи Kubernetes.

Те же 3 сервера, но теперь они управляются Kubernetes.

  1. Автомасштабирование

    • При наплыве покупателей Kubernetes автоматически запускает дополнительные копии серверов №1 и №3.

    • Когда нагрузка падает – лишние сервера отключаются.

  2. Отказоустойчивость

    • Если сервер №2 (база данных) упал, Kubernetes сразу переключает нагрузку на его резервную копию.

    • Покупатели даже не замечают проблемы.

  3. Гибкие обновления

    • Вы хотите обновить API (сервер №3).

    • Kubernetes делает это без downtime:

      • Запускает новые версии API, переключает трафик на них и останавливает старые.

  4. Экономия денег

    • Ночью, когда магазин почти не используют, Kubernetes отключает часть серверов.

    • Утром – снова включает.

Что это даёт бизнесу?

  • Магазин не "падает" в пиковые нагрузки (Чёрная пятница, распродажи).

  • Нет потери заказов – если что-то сломалось, система сама всё починит.

  • Быстрые обновления – можно выпускать новые фичи без остановки магазина.

  • Экономия на серверах – не нужно держать "лишние" мощности.

Kubernetes: мощный инструмент, но не серебряная пуля

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

Термин k8s является синонимом Kubernetes и означает 8 букв между первой и последней буквой. Да, программисты любят сокращения :)

Примерно с 2018 года мы наблюдаем устойчивый тренд: Kubernetes стал синонимом «правильной» продакшн-инфраструктуры. И это не случайно. Он действительно решает множество проблем, связанных с управлением микросервисами, масштабированием, отказоустойчивостью и обновлением без простоев.

Когда Kubernetes оправдан:

  • Микросервисная архитектура с большим количеством сервисов.

  • Необходимость автоматического масштабирования под нагрузку.

  • Высокие требования к отказоустойчивости.

  • Гибкость деплоя (Canary, Blue-Green, A/B-тестирование).

Когда Kubernetes — избыточное решение:

  • Монолитное приложение с низкой нагрузкой.

  • Маленькие проекты без потребности в масштабировании.

  • Стартапы с ограниченным бюджетом.

  • Проект для демо или MVP, в которых планируется масштабирования только после получения инвестиций

  • Команда не готова к сложности k8s (обучение и поддержка требуют ресурсов).

В компании AppFox мы используем Kubernetes при построения кластеров для мультиплеерных игр и проектов со сложной микросервисной архитектурой. В частности, мы его использовали при разработке решений для СберБанка и Банка ВТБ.

Основные понятия Kubernetes

  • Pod — минимальная единица развертывания (может содержать один или несколько контейнеров).

  • Deployment — декларативное описание желаемого состояния приложения.

  • Service — абстракция для доступа к подам (ClusterIP, NodePort, LoadBalancer).

  • Ingress — управление внешним трафиком (роутинг, SSL).

  • ConfigMap & Secret — хранение конфигураций и чувствительных данных.

  • PersistentVolume (PV) & PersistentVolumeClaim (PVC) — работа с постоянным хранилищем.

  • Helm — менеджер пакетов для k8s (чарты).

Вопросы по Kubernetes на собеседовании

Теперь самое интересное — какие вопросы задают кандидатам в зависимости от их уровня.

Для backend-разработчика

Что такое контейнер и зачем нужен Docker?

  • Контейнер - это изолированное окружение для запуска приложений со всеми зависимостями.

  • Docker - платформа для создания и управления контейнерами.

Разница между Docker и Kubernetes

  • Docker создает контейнеры

  • Kubernetes управляет множеством контейнеров на разных серверах.

Как работает kubectl get pods? Что выведет эта команда?

Команда показывает список подов (pods) - минимальных единиц развертывания в k8s. Вывод включает имя пода, статус, количество рестартов и возраст.

Что такое Deployment и зачем он нужен?

Это объект k8s для декларативного управления подами. Позволяет:

  • Разворачивать приложения

  • Обновлять их (rolling update)

  • Возвращаться к предыдущим версиям (rollback)

  • Масштабировать количество реплик

Как приложение в k8s получает конфигурацию (ConfigMap, Secrets)?

  • ConfigMap хранит конфигурации (например, настройки приложения)

  • Secrets - чувствительные данные (пароли, токены). Они монтируются в поды как файлы или переменные окружения.

Что такое Pod, Deployment и Service?

  • Pod — это минимальная единица в Kubernetes

  • Deployment управляет жизненным циклом Pod'ов

  • Service предоставляет сетевой доступ.

Как подать переменные окружения в Pod?

Через env, envFrom, ConfigMap, Secret.

Что произойдет, если Pod упал?

Kubernetes сам его перезапустит — важно понимать работу контроллеров.

Для Junior DevOps

Как создать под с помощью kubectl?

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Как посмотреть логи пода?

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Как работает Service? Какие типы сервисов знаете?

Абстракция для доступа к набору подов. Типы:

  • ClusterIP (внутренний IP)

  • NodePort (порт на каждой ноде)

  • LoadBalancer (внешний балансировщик)

  • ExternalName (CNAME-запись)

Как обновить приложение в k8s (стратегии деплоя)?

  • RollingUpdate (постепенная замена подов)

  • Recreate (удаление всех старых перед созданием новых)

Что делает kubelet и kube-proxy?

  • kubelet - агент на нодах, запускает и контролирует контейнеры

  • kube-proxy - обеспечивает сетевую связность между сервисами

Как создать кластер Kubernetes?

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост
Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост
Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Как подключить volume к Pod'у?

Volume (том) в Kubernetes позволяет сохранять данные между перезапусками Pod'ов. Есть несколько типов томов, но для постоянного хранения данных используются PersistentVolume (PV) и PersistentVolumeClaim (PVC).

  • PersistentVolume — это ресурс в кластере, представляющий физическое хранилище (например, диск в облаке или NFS-шару). PV создаётся администратором кластера и существует независимо от Pod'ов.

  • PersistentVolumeClaim — запрос Pod'а на выделение PV. PVC связывается с подходящим PV (или динамически создаёт его, если настроен StorageClass). PVC монтируется в Pod как volume. Если не хочется создавать PV вручную, можно использовать StorageClass для автоматического создания томов.

Чем отличается Horizontal Pod Autoscaler от Vertical Pod Autoscaler?

  • HPA масштабирует количество Pod'ов на основе метрик нагрузки (увеличивает или уменьшает число реплик (replicas) Deployment'а в зависимости от, например, CPU или памяти, т.е., нагрузка выросла — добавили ещё Pod'ов).

  • VPA изменяет ресурсы (CPU, память) у контейнеров внутри Pod'а

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Для Middle DevOps

Как настроить Ingress для доступа к сервису?

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост
Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Как сделать Horizontal Pod Autoscaler (HPA)?

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост
Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Как управлять ресурсами (requests/limits)?

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Как настроить PersistentVolume для stateful-приложения?

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Как диагностировать проблему с CrashLoopBackOff?

  1. Посмотреть логи пода

  2. Проверить readiness/liveness пробы

  3. Убедиться, что контейнеру хватает ресурсов

  4. Проверить монтирование томов

  5. Изучить события кластера:kubectl describe pod <pod-name>kubectl get events

Для Senior DevOps

Как настроить NetworkPolicy для изоляции подов?

Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост
Kubernetes в продакшене: основные понятия и вопросы на собеседовании IT, Разработка, Системное администрирование, Программирование, Программист, Kubernetes, Интервью, Собеседование, DevOps, Серверная, Оптимизация, Длиннопост

Как работает etcd и что делать при его проблемах?

Распределенное key-value хранилище - "мозг" Kubernetes. Проблемы и решения:

  • Недостаток места: регулярная дефрагментация

  • Высокая задержка: оптимизация сети

  • Потеря кворума: восстановление из бэкапа

Как настроить мониторинг (Prometheus + Grafana)?

  1. Установка Prometheus Operator

  2. Настройка ServiceMonitor для сбора метрик

  3. Создание Grafana дашбордов

  4. Настройка алертов через Alertmanager

Как организовать multi-cluster управление?

Варианты:

  • Kubefed (Federation v2)

  • Cluster API

  • Коммерческие решения (GKE Anthos, EKS Anywhere)
    Основные задачи: синхронизация ресурсов, единая аутентификация, централизованное логирование.

Как оптимизировать costs в облачном k8s (автоскейлинг нод)?

  • Использование spot-инстансов

  • Автомасштабирование нод (Cluster Autoscaler)

  • Вертикальное масштабирование подов (VPA)

  • Планирование подов на дешевые ноды (node affinity/taints)

  • Использование serverless-решений (AWS Fargate, GCP Cloud Run)

Заключение: Kubernetes — мощный инструмент, но не панацея

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

Главный совет:

  • Если у вас микросервисы, высокая нагрузка или требовательная инфраструктура — Kubernetes может стать вашим решением.

  • Если проект небольшой или монолитный — начните с простых решений (Docker Compose, managed-сервисов) и масштабируйтесь постепенно.

Попробуйте Kubernetes в действии:

  • Разверните локальный кластер через minikube или kind.

  • Поэкспериментируйте с Helm-чартами и автоскейлингом.

  • Изучите managed-решения (GKE/EKS/AKS), чтобы оценить их преимущества.

Показать полностью 15
[моё] IT Разработка Системное администрирование Программирование Программист Kubernetes Интервью Собеседование DevOps Серверная Оптимизация Длиннопост
3
ChugaDevOps
1 месяц назад

Кратко об архитектуре Микросервисов⁠⁠

Микросервисная архитектура позволяет поставлять новые обновления конечным пользователям быстрее и качественнее главное не переборщить с количеством микросервисов.
Микросервис должен предоставлять функционал из одной области.
Связи между микросервисами не должны превышать более 2 или максимум 3.
Чем больше связей тем сложнее разработка и поддержка обратной совместимости.

IT DevOps Микросервисы Программирование Автоматизация Текст
16
ChugaDevOps
1 месяц назад

Секреты DevOps⁠⁠

Делюсь опытом и наработками по направлению DevOps.
Отвечу на любой ваш вопрос.

Буду рад, если мои знания найдут практическое применение.

DevOps IT Linux Программирование Gitlab Образование Текст
27

Попробовать мобильный офис

Перейти
Партнёрский материал Реклама
specials
specials

Мобильный офис до 100 тысяч рублей⁠⁠

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

Протестировали TECNO MEGABOOK K15S вместе со смартфоном TECNO CAMON 40 и наушниками TECNO в рабочих и бытовых сценариях от Zoom-звонков до перелета, а теперь рассказываем, как себя показала техника.

Первое впечатление от дизайна ноутбука

Первое, что заметно — это вес. При диагонали 15,6 дюйма и полностью металлическом корпусе K15S весит всего 1,7 кг. Это примерно на 15% меньше, чем аналоги. Устройство не обременяет ни в офисе, ни в такси. Ноутбук поместился в стандартный городской рюкзак, было удобно достать его в кафе за завтраком и по дороге в такси, чтобы быстро отработать клиентские правки.

1/4

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

Шарнир работает мягко: чтобы открыть крышку даже одной рукой, не нужно придерживать корпус. Чтобы показать коллеге или клиенту презентацию, достаточно раскрыть экран на 180°. Это удобно и для работы лежа, и для подставок, которые требуют определенного угла обзора.

Также отметим 9 портов: USB-A, USB-C, HDMI, слот для карты памяти — можно забыть о переходниках.

В TECNO MEGABOOK K15S предустановлен Windows 11. Ноутбук готов к работе сразу после включения. Никаких лишних установок и обновлений. Все настроено и оптимизировано для вашей многозадачности.

Экран: яркая картинка и комфорт ночью

Экран — 15,6 дюйма, IPS-матрица с разрешением Full HD. Углы обзора отличные: изображение остается четким, даже если смотреть сбоку, цвета не искажаются. Есть антибликовое покрытие. Тестировали ноутбук при разном освещении: можно спокойно работать у окна. Когда солнце бьет прямо в экран, текст по-прежнему остается читаемым, картинки не искажаются. Это редкость в бюджетных моделях.

1/2

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

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

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

Производительность: рендерим видео, открываем вкладки

Ноутбук работает на AMD Ryzen 7 5825U (опционально можно выбрать версию техники Intel Core i5-13420H). Восьмиядерный AMD с поддержкой 16 потоков подходит для ресурсоемких операций вроде рендеринга или работы с большими массивами данных. Встроенная графика Radeon справляется с редактированием видео в Full HD или играми.

1/4

Во время монтажа 30-минутного ролика в DaVinci Resolve и параллельной работе в Photoshop с несколькими большими PSD-файлами система сохраняла стабильность. Не было ни зависаний, ни заметного падения производительности. Ноутбук уверенно держит в фоне 10 приложений одновременно. Если запущены браузер с 20 вкладками, видеозвонок в Telegram, Excel с объемной таблицей и софт для монтажа, система не тормозит и не перегревается. Переход между окнами остается плавным, ничего не «проседает», даже при одновременном скачивании файлов и редактировании видео.

Базовая комплектация включает 16 ГБ оперативной памяти в двух слотах. При необходимости можно легко увеличить этот показатель до 32 ГБ, заменив стандартные модули на более емкие. Помимо установленного SSD на 1 ТБ предусмотрен дополнительный слот, поддерживающий диски объемом до 2 ТБ.

Чтобы во время нагрузки системы охлаждения не выходили из строя, в ноутбук встроен эффективный вентилятор, способный рассеивать до 35 Вт тепла. Устройство не греется, его спокойно можно держать на коленях. Это решение дополнено тремя режимами работы, которые переключаются простой комбинацией клавиш Ctrl+Alt+T. Тихий режим идеален для работы ночью или в общественных местах, сбалансированный подходит для повседневных задач. Производительный, на котором запускали рендеринг видео и игры, практически не шумит.

Автономность: 15 часов без подзарядки

Протестили автономность MEGABOOK K15S в условиях, знакомых каждому деловому путешественнику. Утром перед вылетом зарядили ноутбук до 100% и взяли его в рейс Москва — Калининград. В зале ожидания провели созвон, потом три часа смотрели сериал и в дороге до отеля редактировали документы. К моменту приезда оставалось 40% заряда: хватило бы еще на пару часов продуктивной работы.

1/3

MEGABOOK K15S может автономно работать до 15 часов и позволяет не оглядываться на индикатор заряда. Заявленное время достигается при типичном офисном использовании: одновременная работа с документами в Word и Excel, ведение переписки, видеоконференции, веб-серфинг.

Если все же понадобится, за  час восполняется до 70% батареи. Компактный адаптер мощностью 65 Вт на базе нитрида галлия поместился даже в карман пиджака. Один блок питания заряжает и ноутбук, и смартфон, и наушники. Экономия места: не нужно никаких дополнительных проводов.

Звук, который реально слышно

В TECNO MEGABOOK K15S установлены два мощных динамика по 2.5 Вт. Звук с глубокими низами, без пластикового дребезжания, объемный. Благодаря DTS можно смотреть видео даже в шумном помещении. В тестах специально включали сцены с шагами и выстрелами: локализация настолько точная, что в наушниках нет необходимости.

Та же стабильность и в микрофоне. Благодаря AI-шумоподавлению голос передается чисто. Во время тестовых звонков из оживленного кафе собеседник не услышал ни разговоры за соседним столом, ни городской шум. И все это — на расстоянии до пяти метров.

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

Для тех, кто предпочитает гарнитуру, идеально подойдут беспроводные наушники TECNO FreeHear 1 из экосистемы бренда. Когда не хотелось делиться разговорами с окружающими, подключали их. Чистый звук с акцентом на средние частоты, 11-мм драйверы, которые выдают неожиданную детализацию. Музыку слушать приятно: и фоновый плейлист на телефоне, и вечерний сериал на ноутбуке. Автономно работают наушники 6 часов, с кейсом — до 30 часов. 

1/2

Bluetooth 5.4 обеспечивает стабильное соединение на расстоянии до 10 метров. Удобная C-образная форма разработана специально для длительного ношения — после восьмичасового рабочего дня в ушах не возникает дискомфорта. Наушники поддерживают одновременное подключение к ноутбуку и смартфону. Переключение между устройствами происходит быстро и без заминок.

Через фирменное приложение Welife можно выбрать один из четырех эквалайзеров и отследить местоположение гарнитуры в случае утери. А еще кастомизировать виджет для управления наушниками. Функция настройки персонализированного дизайна доступна для устройств на Android и позволяет гибко изменить внешний вид окна подключения: вплоть до установки фоновой картинки или собственного фото.

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

Бесшовная синхронизация со смартфоном

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

Функция выручила, когда нужно было открыть приложение, у которого нет веб-версии. Удобно работает и буфер обмена: скопировал текст на одном устройстве — вставил на другом. Например, код, полученный в сообщении на телефоне, вводится в браузере на ноутбуке. Экономит минуты, а иногда и нервы. А когда в дороге пропал Wi-Fi, ноутбук сам подключился к мобильному интернету через смартфон.

1/2

TECNO CAMON 40 и сам по себе — мощный рабочий инструмент.  Смартфон выделяется камерой высокого качества 50 Мп, ярким AMOLED-экраном 120 Гц и множеством функций, которые упрощают процесс мобильной съёмки и использование искусственного интеллекта TECNO AI.

Телефон работает на HIOS 15.0.1 на базе Android 15.В фирменную оболочку встроен искусственный интеллект:

  • Голосовой помощник Ella. Отвечает на вопросы, помогает с задачами и управлением устройством.

  • Решение задач. Наводите камеру на задачу, ИИ решает ее.

  • AI Редактор фотографий. Интеллектуальная обработка в одно касание.

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

Технические характеристики

  • Процессор и память. 8 ядер, 16 потоков, Кэш L3 16 МБ, частота до 4.5 ГГц Графический процессор AMD Radeon™ graphics SSD 512 ГБ или 1 ТБ, М.2, 2280, PCle 3.0 Nvme DDR4 16 ГБ, 3200 МГц.

  • Дисплей. 15.6", TFT, Full HD (1920×1080), 16:9, 280нит, 45% NTSC, 16.7 млн цветов, 60 Гц, 141 ррі.

  • Веб-камера. 1 Мп, шторка приватности.

  • Порты. 9 портов: 1*TF Card (microSD), 1*HDMI 1.4, 1*USB-A 3.1,

    1*USB-A 3.2, 1*3.5mm аудиовход, *Ethernet RJ45 до 1 Гбит, 2*Туре-С (Full Function), 1*слот для замка Kensington.

  • Другое. Сканер отпечатка пальца в кнопке питания. Клавиатура с подсветкой (4 уровня яркости). Тачпад с поддержкой одновременно 4 касаний.

  • Батарея. 70 Вт∙ч (6150 мА∙ч), Li-Pol, 11.55 B 65 Вт Type-C GaN, 20 В, 3.25 А, кабель 1.8 м (Туре-С-Type-C).

  • Габариты. 17.3 мм (высота), 359.5 мм (ширина), 236 мм (глубина).

  • Вес. 1,7 кг.


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

КУПИТЬ НОУТБУК TECNO

Реклама TECNO Mobile Limited, Юридический адрес: Flat N, 16/F., Block B, Универсальный промышленный центр, 19-25 Shan MeiStreet, Fotan, New Territories, Гонконг

Показать полностью 17
Электроника Гаджеты Ноутбук Длиннопост
1
eSimOnOff
eSimOnOff
1 месяц назад
Серия Фреймворк управления IT-компанией

CTO в разрезе: как устроена его конфигурация по уровням компании⁠⁠

CTO в разрезе: как устроена его конфигурация по уровням компании DevOps, Разработка, Развитие, IT, Инженер, Длиннопост

В прошлый раз мы обсуждали PDCA — про оценку того, как рук-ль работает с командой. Теперь — о командах, на уровнях которых работает CTO (будем для общности называть его руководителем технического домена). CTO работает не только с разработкой. Его зона ответственности охватывает множество бизнес-доменов — от аналитики до маркетинга. Разберём, как это устроено на разных уровнях компании, определив, с кем он взаимодействует и из чего складывается оценка его деятельности.

[1 и 2] Операционно-тактический уровень - технари и тимлиды

Это, конечно, технарские команды, которых может быть несколько. Такой вот уровень работы «на земле» — операционный. Там и «бекенды», и «фронты», и мобильщики, и тестировщики, и технические писатели и т. д. и т. п. В общем, все те, кто работают руками.

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

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

Оценка CTO складывается из успешности работы по управленческой (тимлидской) и технарской (техника) частям.

[3] Уровень эксплуатации (operations) - инфра, кадры, бухгалтерия и пр.

Улучшения продуктов поднимаются на следующий уровень — уровень эксплуатации (operations). Ради него и пишется документация техническими писателями, настраиваются CI/CD девопсами — в общем, делается всё, чтобы уровень развития, как первые ступени ракеты, в любой момент бизнес мог отбросить как выполнившие свою функцию. Уровень эксплуатации — это уже третий уровень.

Здесь находятся техподдержка, те специалисты из DevOps-команд, которые занимаются эксплуатацией (мониторинг, алерты, инциденты и т. д.). Здесь идёт постоянно активное взаимодействие с эксплуатацией других доменов — например, HR, юридической поддержкой, Отделом Кадров, АХО, бухгалтерией и т. п.

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

Здесь CTO взаимодействует с доменами DevOps, технической поддержки, внутренней безопасности, IT-инфраструктуры, а также доменами административных и кадровых служб, от которых зависит стабильность.

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

[4] Стратегический уровень - бизнес

Следующий уровень — бизнес-команда или C-level. Это уровень стратегии с долгосрочными перспективами. Это команда руководителей других доменов, с которыми идёт активное взаимодействие для координации общей стратегии по улучшению бизнес-модели. Если на уровне эксплуатации CTO ещё мог не взаимодействовать с продажами или маркетингом, то здесь у него идёт активнейшее взаимодействие с ними.

CTO на этом уровне включается во взаимодействие с доменами продаж, маркетинга, клиентского успеха, даже если они ему не подчиняются. Его задача — донести ограничения и возможности технологий до тех, кто строит бизнес-модель.

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

[5] Внешний контур - рынок

И последний уровень — внешний контур, рынок. То, ради чего всё.

На самом деле вся компания со всеми доменами и уровнями — это его (рынка) гипотеза. Рынок, по сути, проверяет гипотезу (в виде инвестиций), экспертизой (в виде сотрудников и консультантов). Рынок может даже проводить валидацию. Это может быть due diligence от инвесторов, ревью со стороны партнёров или требования аудиторов в регуляторной среде. Если гипотеза оказывается верной — он меняет инвестиции финансов и внимания кастомеров на ценность, предоставляемую продуктами компании.

Оценка CTO здесь складывается из способности активно взаимодействовать с рынком по всем направлениям: от привлечения экспертизы до прохождения аудитов.

Итог

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

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

Домашнее задание для закрепления

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

– в знаменателе — их реальные ожидания от вас,
– в числителе — то, как вы презентуете свою работу по этим ожиданиям перед стейкхолдерами;

Такая простая модель быстро покажет, где возникает разрыв — и что стоит развивать или делегировать.

Показать полностью 1
[моё] DevOps Разработка Развитие IT Инженер Длиннопост
0
Посты не найдены
О нас
О Пикабу Контакты Реклама Сообщить об ошибке Сообщить о нарушении законодательства Отзывы и предложения Новости Пикабу Мобильное приложение RSS
Информация
Помощь Кодекс Пикабу Команда Пикабу Конфиденциальность Правила соцсети О рекомендациях О компании
Наши проекты
Блоги Работа Промокоды Игры Курсы
Партнёры
Промокоды Биг Гик Промокоды Lamoda Промокоды Мвидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии