Всем привет! Меня зовут Даниил и я у мамы –
программист DevOps


❗️Не много обо мне:

🙂 Мне 21 год. С 2024 года я работаю dev-ops инженером в одной крупной IT-компании.

🐤 Айтишечкой я начал интересоваться еще в школе, а если быть точнее в классе 9-10🧐. Как наверное у всех школьников с программированием я познакомился с паскаля🤮. Позже узнал о существовании питона и написал пентагон своего первого телеграмм бота😊. Охх... Это было очень круто, за лето сделал наговнокодил несколько ботов и понял, что хочу связать свою жизнь с программированием.

✈️ А далее пошло по накатанной(вообще нет): поступил в технический вуз, жестко ботал Django, Flask, верстку, JS, пробовал себя в android разработке, участвовал в хакатонах и различных других движухах. И к концу 2 курса очень серьёзно занялся поиском работы.

🧋 И тут начинается самое интересное. Сначала попал на практику от универа в маленькую компанию и проработал там 2 дня😄. Из задач там было переносить документы из PDF в HTML. Дико скучно, уволился. Потом было много собеседований. О dev-ops в то время практически не имел представления и искал работу python разработчиком на Django. Отправлял резюме во все возможные компании.

✅ И наконец получил 2 оффера: python-разработчиком и dev-ops инженером(совсем случайно, просто в резюме указал знание docker). И выбрал 2 вариант, так как там были условия интереснее и команда больше понравилась. И вот я оказался в этой лодке в открытом море неизведанных IT технологий, но это уже история для следующих постов!


❓Для чего этот канал:

О создании своего телеграмм канала задумывался давно, но все откладывал (а кто так не делает:)

И вот наконец, пришло время.

Здесь я хочу делиться своими мыслями, трудностями, историями из жизни на сложном, но интересном пути молодого dev-ops инженера. Показывать лайфхаки, рассказывать о крутых технологиях, вместе кодить и веселиться!🤪
Расскажу, как из школьника не умеющего переустановить виндовс стал автоматизатором автоматизации и получил первый оффер.🐸


💡Для кого этот канал:

➖ желающие стать dev-ops
➖ все, кому интересны практики dev-ops.
➖ действующие инженеры, которые хотят посмотреть на работу других
➖ те, кто только начинает свой путь в IT и еще не определился с профессией
➖ желающие узнать новые технологии, вырасти профессионально, научиться проходить собеседования на чужом опыте


————
Подписывайтесь, чтобы вместе глотать кофе, чинить (ну или ронять, тут как повезет) прод и получать кайф от этой сумасшедшей 🔤🔤-жизни!

📞 связаться со мной: @danlylacov

DevOps и DevOps-инженер: Кто это, зачем он нужен и почему все хотят его захантить? 

DevOps — это модно. DevOps — это дорого. DevOps — это «надо внедрить». Но что это на самом деле? И кто такой этот загадочный DevOps-инженер? Давайте разберёмся без заумных терминов и маркетинговой шелухи. 


👎  DevOps — это не... 

❌ Не должность. Нет такой вакансии «Волшебник DevOps», который одним взмахом руки чинит все сервера. 
❌ Не инструмент. Это не  Jenkins, не Docker и не Kubernetes (хотя они помогают). 
❌ Не серебряная пуля. Не решит все проблемы, если в компании бардак. 

💡 DevOps — это культура, которая ломает стену между разработчиками и админами. 


🐤  Кто такой DevOps-инженер? 

Если коротко: это гибрид программиста, админа и автоматизатора. 

Чем он занимается? 
✅ Автоматизирует всё, что можно: сборку, тестирование, деплой. 
✅ Настраивает CI/CD, чтобы код сам тестировался и выкатывался. 
✅ Управляет инфраструктурой через код (Terraform, Ansible). 
✅ Следит за тем, чтобы сервисы не падали (мониторинг, логи). 
✅ Оптимизирует процессы, чтобы все работало быстрее и надежнее. 


❓Почему его все хотят? 
➖ Потому что он экономит кучу времени и нервов команды. 
➖ Потому что без него релизы — это лотерея. 
➖ Потому что он знает и код, и сервера — универсальный солдат. 


❓ Откуда он вообще взялся? 

Раньше было так: 
1️⃣ Разработчики писали код. 
2️⃣ Кидали его админам со словами *«Разверни, но у меня всё работает»*. 
3️⃣ Админы матерились, потому что ничего не работало. 
4️⃣ Все ждали релиза полгода, а потом неделю чинили продакшен. 

Потом появились DevOps-инженеры и сказали: 

«Давайте автоматизируем эту боль!»

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


⚡️ Основные принципы (без воды) 

1️⃣ Автоматизируй всё, что можно 
- Ручные действия = ошибки. 
- Если делаешь что-то больше двух раз — пиши скрипт. 

2️⃣ Выпускай чаще 
- Лучше 10 маленьких обновлений, чем один большой взрывной релиз. 
- Так баги легче ловить. 

3️⃣ Тестируй заранее 
- «У меня на машине работало» — не аргумент. 
- Настроил CI/CD? Добавь туда тесты. 

4️⃣ Мониторь всё 
- Если продакшен упал, а ты узнал об этом от пользователей — ты уже проиграл. 

5️⃣ Развивай культуру, а не инструменты 
- Можно купить весь софт, но если команда не хочет меняться — ничего не выйдет. 


🛠️ Что должен знать DevOps-инженер? 

- Git📱 — чтобы код не терялся. 
- Docker🐘 — чтобы приложения работали везде одинаково. 
- Kubernetes📱— чтобы управлять кучей контейнеров. 
- Terraform/Ansible📱 — чтобы настраивать инфраструктуру кодом. 
- CI/CD (GitLab CI, GitHub Actions, Jenkins)📱 — чтобы автоматизировать сборку и деплой. 
- Мониторинг (Prometheus, Grafana, ELK)📈 — чтобы видеть, что всё в порядке. 


❓ Зачем всё это? 

Чтобы: 
✅ Релизы перестали быть болью (можно выпускать обновления хоть каждый день). 
✅ Продакшен ломался реже (потому что тесты и мониторинг). 
✅ Разработчики и админы перестали ненавидеть друг друга (общие цели = меньше трэша).

⬇️Навигация по каналу⬇️

Ну и вот пришло время задуматься о будущем канала и о постах в нем⭐️

💡 Каждый пост канала будет сопровождаться одним из хештeгов:

#основыDevOps - тут будет по порядку и структурированно освещаться все, чтобы войти в профессию

#DevOpsStories - спонтанные и чиловые истории из жизни

#SuperGuides - простенькие шпаргалки и гайды

#ITmemes - мемчики, ну а куда без них🙂

#think - просто мысли о житухе, развитию и work die life balance

#challenge - вызовы и челенджи, просто развлекаемся тыкая кнопочки


Во всех категориях постов кроме #основыDevOps, посты будут выходить спонтанно и по мере вдохновения и сочинения Даней🐸



❗️А вот по основам хочу сделать четкий план развития
(в будущем будет дополняться ссылками по мере написания):

➖ БАЗА 
🟢Linux: ключевые команды, процессы, сети 
*️⃣Linux: главный друг DevOps и 20 команд, которые спасают задницу
*️⃣Логи в Linux: как читать и не утонуть в /var/log
*️⃣Права в Linux простыми словами
*️⃣Сетевые утилиты в Linux
*️⃣Настройка сервисов: systemd, cron, journalctl

🟢Windows: PowerShell, автоматизация 
🟢Python: скрипты для автоматизации 

➖ ОСНОВЫ DEVOPS 
🟢 Git, CI/CD (Jenkins, GitHub Actions) 
🟢Docker: от основ до оптимизации 
🟢Kubernetes: кластеры, деплой 

➖ АВТОМАТИЗАЦИЯ 
🟢Terraform: облачная инфраструктура 
🟢Ansible: настройка серверов 

➖МОНИТОРИНГ И БЕЗОПАСНОСТЬ 
🟢Prometheus + Grafana 
🟢DevSecOps: сканирование кода и контейнеров 

➖ PRO-ТЕМЫ 
🟢GitOps (ArgoCD) 
🟢Облака (AWS/GCP) 
🟢Оптимизация затрат и производительности

#основыDevOps

Linux: главный друг DevOps и 20 команд, которые спасают задницу


🔜 Что такое Linux простыми словами?
Linux📱— это операционная система, но не одна штука, а целая экосистема.
В основе — ядро (kernel), которое рулит железом.
Сверху — разные «сборки» (дистрибутивы): Ubuntu, Debian, CentOS, Fedora, Arch (для самых смелых 👻).

90% серверов в мире работают на Linux. Даже если у тебя Windows на ноуте — всё равно в облаке, где живёт твой код, будет Linux.


❓Почему DevOps обязан знать Linux?
Серверы = Linux.
Docker = Linux (контейнеры используют ядро Linux).
Kubernetes = Linux.
Jenkins, GitLab, Ansible, Terraform — всё это работает лучше на Linux.

Если ты не знаешь Linux, ты как хирург без скальпеля. Можно попробовать работать ложкой, но… результат будет так себе ☹️.




⚡️ 20 команд, без которых ты не DevOps
🟡 1–4: Основы навигации

pwd — показать, где ты находишься (Print Working Directory).

ls -la — список файлов и папок (с правами, владельцами и скрытыми файлами).

cd /путь/ — перейти в директорию.

tree — показать структуру папок (не везде предустановлен, но must-have).

❗️ Без этого ты как в лесу без карты.

🟡 5–8: Работа с файлами

cat file.txt — вывести содержимое.

less file.txt — читать файл с прокруткой.

head -n 20 file.txt — показать первые 20 строк.

tail -f logs.txt — читать логи «вживую» (must-have для продакшена😀).

🟡 9–12: Управление файлами и правами

touch new.txt — создать пустой файл.

mkdir new_folder — создать директорию.

chmod 755 script.sh — изменить права доступа.

chown user:group file.txt — сменить владельца файла.

⚡️ Права в Linux — это святое. Если не знаешь chmod, будешь долго материться.

🟡13–15: Процессы и системы

ps aux — список процессов.
top или htop — мониторинг загрузки системы.

kill -9 PID — убить зависший процесс (и да, иногда прод падает именно после этого 🙃)

👉 Без этого ты не сможешь понять, кто жрёт всю память или почему сервер висит.

🟡16–18: Сеть

ping google.com — проверить, доступен ли хост.

curl http://site.com — отправить HTTP-запрос.

ss -tulnp или netstat -tulnp — показать открытые порты.

🟡 19–20: Админские must-have

systemctl status service — проверить, работает ли сервис.

journalctl -u service -f — читать логи конкретного сервиса в реальном времени.

🍀 Если у тебя не запускается nginx или docker — это твои лучшие друзья.


💡 Итого
Linux — это не просто ОС. Для DevOps это 🗿 «базовый уровень».
Выучив эти 20 команд, ты:
😀 научишься ориентироваться в системе,
😀 поймёшь, как читать и дебажить логи,
😀 сможешь управлять процессами и сервисами,
😀 не будешь паниковать, когда всё упало.

#основыDevOps


Логи в Linux: как читать и не утонуть в /var/log

В мире DevOps есть два состояния:
Всё работает 👍
«Почему всё упало?» 🧑‍💻

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

❓ Где живут логи в Linux?

По умолчанию — в папке /var/log.

Там можно найти целый зоопарк:

/var/log/syslog # системные события (Ubuntu/Debian)
var/log/messages # системные события (CentOS/RHEL) 
/var/log/auth.log # авторизация, ssh-логины 
var/log/kern.log # ядро Linux 
var/log/nginx # логи nginx
var/log/mysql # логи MySQL

💡 Совет: если что-то не работает — первым делом загляни в /var/log.

❗️ Как читать логи?

1️⃣ tail — смотри последние строки

tail -f /var/log/syslog # новые записи в реальном времени

2️⃣ less — удобно листать

less /var/log/syslog

👉 Навигация: Space (вниз), b (назад), q (выйти).

3️⃣grep — ищем конкретно

grep "error" /var/log/syslog # найти ошибки 
grep -i "nginx" /var/log/syslog # игнор регистра 
grep -r "fatal" /var/log/ # искать во всех файлах

👉 Экономит часы жизни: не надо глазами искать слово «ERROR» среди тысячи строк.

4️⃣ journalctl — системные логи через systemd

journalctl -u nginx.service --since "10 min ago" # логи nginx за последние 10 минут
 journalctl -xe # последние ошибки системы 
journalctl -f # новые записи (как tail -f)

👉 Если сервис запущен через systemd, то это лучший способ понять, почему он не стартует.

5️⃣ dmesg — ядро Linux

dmesg | tail -n 20

👉 Полезно, если проблемы с железом или драйверами (например, диск отвалился).


💡 Практический сценарий
Представь: ты выкатываешь новую версию сервиса, и он не запускается.

План действий DevOps:
Проверяешь статус сервиса:

systemctl status myapp

Смотришь его логи:

journalctl -u myapp for

Если там пусто — лезешь в /var/log/.
Ищешь ошибки:

grep "error" /var/log/syslog

🍒 В 90% случаев уже на этом этапе находишь причину.


⭐️ Итого
Логи — это твои глаза в Linux.
✔️ Запомни:

без логов ты слепой DevOps.

С ними ты всегда можешь понять: «почему всё упало» и «кто виноват».

#SuperGuides

Vim для DevOps: как не выйти из себя


Vim — редактор текста, который встречает тебя пустым экраном и вопросом:
🔜«А как отсюда выйти?»


Вот небольшая шпаргалка, чтобы выжить:
🟡 Открыть файл

vim filename.txt

🟡Режимы

i — вставка (печатаем текст)
Esc — вернуться в командный режим
: — ввод команд

🟡 Выход из Vim

:q # выйти (если без изменений) 
:q! # выйти без сохранения 
:wq # сохранить и выйти 

🟡 Полезное

dd # удалить строку 
yy # скопировать строку 
p # вставить скопированное 
u # отмена (undo)

💡 Запомни:

Vim либо полюбишь, либо будешь ненавидеть, но знать его должен каждый DevOps.

#основыDevOps

Права в Linux простыми словами


💡 Представь, что файл – это комната. У неё есть три категории гостей:

🐤Владелец – хозяин комнаты

🐥🐸 Группа – его друзья

🏠 Остальные – все остальные люди


Каждому гостю можно дать разные возможности:

r (read) – можно заглянуть (читать файл / смотреть, что в папке)

w (write) – можно переставить мебель (изменять/удалять)

x (execute) – можно включить свет и пользоваться (запустить программу / зайти в папку)


✏️ Как менять права

chmod – «какие ключи дать гостям»

chmod u+x script.sh   # дать владельцу право запускать
chmod g-w file.txt    # забрать у группы право менять
chmod o+r notes.txt   # разрешить остальным читать

u = user (владелец),
g = group (группа),
o = others (остальные).


chown – «кто хозяин комнаты»

chown dan:devops file.txt

Теперь хозяин – dan, его друзья – группа devops.


ACL – «пропуск по именам»
Если нужно дать доступ конкретному человеку:

setfacl -m u:alex:rw file.txt

Теперь alex может читать и менять файл, даже если он не владелец и не в группе.


✅ Итого:

chmod – раздаём ключи (читать, менять, запускать)

chown – меняем хозяина

ACL – даём доступ конкретным людям

#основыDevOps

Сетевые утилиты в Linux

Сеть в Linux можно проверять и диагностировать десятками способов, но эти 4 утилиты — базовый «джентльменский набор».

1️⃣ ping — жив ли хост?

Команда отправляет специальные пакеты (ICMP Echo Request) и ждёт ответ (Echo Reply).

Пример:

ping ya.ru

Что покажет:
🟣 работает ли хост вообще,

🟣 через какое время приходят ответы (latency, задержка),

🟣 сколько пакетов потерялось.

Полезно, если нужно быстро понять:

«а он вообще жив?»

2️⃣ netstat — кто и куда подключён

Старая, но до сих пор встречающаяся утилита.

Пример:

netstat -tulnp

Флаги:

-t — TCP

-u — UDP

-l — слушающие порты

-n — показывать IP и порты цифрами (без DNS-имен)

-p — показать, какой процесс держит порт

🔜 Можно увидеть: «у меня nginx слушает 80-й порт» или «ой, у меня какой-то непонятный процесс висит на 12345».


3️⃣ ss — современный netstat

ss делает то же самое, что netstat, только быстрее и с большим количеством деталей.

Пример:

ss -tulnp

Почти те же флаги, но вывод чище.

Ещё пример:

ss -s

Покажет краткую статистику соединений (сколько TCP/UDP активных, закрытых и т.п.).

🔜 Если привык к netstat, переходи на ss.


4️⃣ tcpdump — что реально летает по сети

Самая мощная из этих утилит. Она перехватывает сетевые пакеты и показывает их содержимое.

Пример:

tcpdump -i eth0 port 80

Здесь:

⏩-i eth0 — интерфейс (обычно eth0, ens33, wlan0)

⏩port 80 — фильтр (смотрим только трафик на 80-й порт)

Можно поймать пакеты и сохранить в файл:

tcpdump -i eth0 -w dump.pcap

А потом открыть в Wireshark для удобного анализа.

🔜 Используется для диагностики, отладки сервисов и даже расследования атак.


✅ Итого:

ping — проверить, жив ли хост и какая задержка

netstat — старый способ посмотреть порты и соединения

ss — новый и быстрый способ

tcpdump — сниффер пакетов, полная картинка сетевого трафика

#devops #linux #network

#основыDevOps

Настройка сервисов: systemd, cron, journalctl

📌В Linux всё крутится вокруг сервисов и планировщиков. Если знать три инструмента — systemd, cron и journalctl, то можно управлять почти всей жизнью сервера.


systemd — повелитель процессов

systemd — это главный диспетчер, который запускает сервисы и следит, чтобы они не падали.

Запустить сервис:

systemctl start nginx

Остановить:

systemctl stop nginx

Включить автозапуск при старте системы:

systemctl enable nginx

Посмотреть статус:

systemctl status nginx

📎 Помни: systemd — это сердце Linux, без него никуда.



cron — планировщик дел

cron — это твой личный секретарь. Он делает задачи по расписанию: бэкапы, чистки логов, скрипты.

Файл расписаний:

crontab -e

Формат:

минуты часы день_месяца месяц день_недели команда

Примеры:

Каждый день в 3 ночи:

0 3 * * * /usr/bin/backup.sh

Каждую минуту (для теста):

* * * * * echo "Живой!"

journalctl — лупа для логов

Все, что делают сервисы под крылом systemd, пишется в журнал.

Логи конкретного сервиса:

journalctl -u nginx

Последние записи (режим tail):

journalctl -u nginx do

Логи после перезагрузки:

journalctl b

📎 Это твой главный друг, когда что-то не запускается.


⏩ В связке они работают так:

systemd запускает сервисы,

cron автоматизирует задачи,

journalctl помогает разобраться, почему всё сломалось

#devops #Linux #cmd

#основыDevOps

Настройка сервисов в Linux: systemd, cron, journalctl

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

И вот тут на помощь приходят systemd, cron и journalctl.


🔜 systemd — главный диспетчер сервисов.

Команды:

systemctl start nginx — запустить сервис
systemctl stop nginx — остановить
systemctl enable nginx — запускать при старте системы
systemctl status nginx — посмотреть состояние

👉 Если сервис падает, то именно через systemd можно настроить автоперезапуск (Restart=always в юните).


🔜 cron — планировщик задач.

Нужно запускать скрипт каждый день в 3 ночи? Пиши в crontab:

0 3 * * * /usr/bin/python3 /home/user/backup.py 

⏰ Формат расписания:
минуты часы день_месяца месяц день_недели команда


🔜 journalctl — просмотр логов.

Все события systemd пишутся сюда

journalctl -u nginx — логи конкретного сервиса
journalctl -f — “хвост” логов в реальном времени
journalctl --since "1 hour ago" — события за последний час

✔️ Итог:

systemd = управление сервисами
cron = автоматизация по времени
journalctl = быстрый доступ к логам

❗️Зная эти три инструмента, ты уже на голову выше обычного пользователя Linux

#SuperGuides

PowerShell vs CMD: что реально нужно DevOps?

Многие, кто впервые сталкивается с Windows-администрированием, открывают чёрное окошко CMD и думают: «Ну вот, как в Linux — терминал, только с другой стороны».
Но на самом деле всё немного сложнее.


😕 CMD

Это пережиток прошлого. По сути, командная оболочка с минимальным набором возможностей: запустить exe, пройтись по каталогам, что-то скопировать. Скрипты на .bat — боль и страдание, особенно если ты привык к удобству bash.
CMD нужен только в редких случаях, когда запускается какой-то очень старый софт или скрипт.


🐈 PowerShell

А вот тут начинается магия. PowerShell — это не просто командная строка, это полноценный объектно-ориентированный шелл.

🟣В отличие от CMD, который возвращает текст, PowerShell работает с объектами. Это значит, что можно легко фильтровать, парсить и обрабатывать данные без костылей.

🟣Встроенные команды называются cmdlets — и их очень много: для работы с файлами, реестром, сетевыми настройками, процессами, сервисами.

🟣Есть поддержка модулей, автодополнение и интеграция с .NET — всё, что нужно для автоматизации.


❓ А что DevOps?

Если ты работаешь с инфраструктурой, CI/CD и автоматизацией — забудь про CMD.
PowerShell — это:
⏩автоматизация развертывания и конфигураций на Windows,
⏩работа с Azure и облаками (есть отдельные модули),
⏩кроссплатформенность (есть PowerShell Core, который работает и на Linux, и на macOS).

По сути, PowerShell для Windows — это то же, чем Bash является для Linux. А CMD — просто исторический багаж.

✔️Вывод:

Если хочешь быть настоящим DevOps, учить PowerShell must-have. А CMD пусть останется для дедов на галере.

#основыDevOps

Автоматизация задач в Windows через PowerShell: топ-20 команд

❗️ PowerShell — это не просто «терминал для Windows». Это мощный инструмент для автоматизации рутинных задач: от управления файлами и сервисами до работы с планировщиком и журналами событий.

👇Ниже я собрал 20 команд, которые помогут тебе почувствовать силу PowerShell.

# 1. Получить справку по команде
Get-Help Get-Process -Full     

# 2. Найти все доступные команды
Get-Command                    

# 3. Список сервисов
Get-Service                    

# 4. Запустить сервис
Start-Service -Name spooler    

# 5. Остановить сервис
Stop-Service -Name spooler     

# 6. Перезапустить сервис
Restart-Service -Name spooler  

# 7. Список процессов
Get-Process                    

# 8. Завершить процесс по имени
Stop-Process -Name notepad     

# 9. Последние 20 событий из системного журнала
Get-EventLog -LogName System -Newest 20  

# 10. Показать файлы и папки (аналог dir)
Get-ChildItem                  

# 11. Скопировать файл
Copy-Item C:\file.txt D:\backup  

# 12. Переместить файл или папку
Move-Item C:\old D:\new        

# 13. Удалить файлы (например, логи)
Remove-Item C:\temp\*.log      

# 14. Создать новый файл
New-Item -ItemType File test.txt  

# 15. Проверить сеть (аналог ping)
Test-Connection google.com     

# 16. Прочитать содержимое файла
Get-Content file.txt           

# 17. Перезаписать файл текстом
Set-Content file.txt "Hello"   

# 18. Добавить строку в конец файла
Add-Content file.txt "New line"

# 19. Список задач планировщика
Get-ScheduledTask              

# 20. История команд
Get-History

✔️ Итог:
Эти 20 команд закрывают 80% базовых задач по автоматизации Windows:
⏩управление сервисами и процессами
⏩работа с файлами
⏩анализ логов
⏩сетевые проверки
⏩задачи по расписанию.

PowerShell = автоматизация + контроль

Удаленка в IT: рай или западня?

Когда-то мы мечтали: «Ах, если бы работать из дома, в пижамке, с котом и без этого дурацкого офиса…»
Я всю свою IT-карьеру работаю на удаленке и хочется рассказать, что это не только удобный стол и «работаю из любой точки мира», но и куча подводных камней.

🐈 Ну и сначала хочется начать с плюсов:
⏩Нет дороги до офиса. Твои 2 часа жизни в день снова твои. Можно спать, можно кодить, можно скролить рилсы или тик-ток.
⏩Работать хоть с Бали, хоть с дивана. Главное — интернет, а дальше все упирается только в фантазию
⏩Гибкость. У кого-то пик продуктивности в 6 утра, у кого-то — в 2 ночи. Удалёнка позволяет работать «под себя». Есть конечно нюансы с созвонами, но все решаемо.
⏩Более удобно совмещать с учебой. Я параллельно с работой учусь в университете. И я вообще не представляю, как я совмещал бы эту историю с офисом.

На этом этапе можно подумать, что удалёнка - это плюс вайб, но не все так просто!

🥲Минусы удаленки:
⏩Дом превращается в работу. И иногда это невыносимо, потому что ты спишь, ешь и учишься "на работе"
⏩Социализация. Никакой зум звонок не заменит реального общения. С удаленкой иногда получается, что за неделю ни разу не выходил из дома)
⏩Прокрастинация. В офисе вряд ли у кого то появится желание поспать по середине рабочего дня, а вот на удалёнке такое случается, и это явно не та прикормка, с которой дуреет тимлид.


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

#SuperGuides

Мониторинг за 5 минут: Prometheus + Grafana

❗️❗️❗️
Данный пост сделан совместно с каналом:

Linux | Network | Devops

подписывайтесь🙂

Хотите быть уверены, что сервер не падает в самый ответственный момент, CPU не забит на 100%, а место на диске не заканчивается внезапно?
Для этого в мире DevOps есть три классических героя: Prometheus, Grafana и Node Exporter.

❓ Что это такое?
⏩ Prometheus - база данных для метрик + «мозг» мониторинга.
Он опрашивает приложения, сервисы и экспортеры, хранит числовые ряды и позволяет писать запросы (PromQL).
⏩ Node Exporter - агент, который запускается на сервере и отдаёт данные о его состоянии: CPU, RAM, диски, сеть. Без него Prometheus будет «слепым» к железу.
⏩ Grafana - удобная панель визуализации. Она умеет подключаться к Prometheus (и не только) и рисовать красивые графики, дашборды и алерты.

В связке это работает так:
Node Exporter 🔜 отдаёт метрики ➡️ Prometheus их собирает 🔜 Grafana отображает.

Шаг 1. Готовим окружение
Установи Docker и Docker Compose.
Проверка:

docker --version docker compose version 

Создай папку проекта:

mkdir monitoring && cd monitoring 

Шаг 2. docker-compose.yml
Файл docker-compose.yml:

version: "3.8"
services:
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  node-exporter:
    image: prom/node-exporter
    ports:
      - "9100:9100"

  grafana:
    image: grafana/grafana-oss
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

✔️ 3 контейнера:
Prometheus собирает метрики,
Node Exporter отдаёт состояние сервера,
Grafana рисует графики.

Шаг 3. Конфиг Prometheus
Файл prometheus.yml - это основной конфигурационный файл Prometheus. В нём указываются, какие сервисы опрашивать, с какой частотой и по каким адресам забирать метрики.
Без него Prometheus не будет знать, откуда брать данные для мониторинга
Файл prometheus.yml:

global:
  scrape_interval: 15s   # глобальный интервал опроса: каждые 15 секунд Prometheus будет забирать метрики

scrape_configs:          # список "job" (задач), которые Prometheus будет опрашивать

  - job_name: 'prometheus'   # имя задания (для удобства в метках и интерфейсе)
    static_configs:          # список статических таргетов (адресов, которые нужно опрашивать)
      - targets: ['prometheus:9090']  
        # здесь мы говорим: опрашивай сам Prometheus по адресу prometheus:9090
        # (контейнер prometheus внутри docker-compose доступен по имени сервиса)

  - job_name: 'node'         # второе задание — сбор метрик с Node Exporter
    static_configs:
      - targets: ['node-exporter:9100']  
        # адрес node-exporter, который отдаёт метрики о состоянии хоста
        # (CPU, память, диски, сеть и т.д.)

Шаг 4. Запуск

docker compose up -d 

✔️ Проверяем:
Prometheus ⏩ http://localhost:9090
Grafana ⏩ http://localhost:3000 (логин/пароль: admin/admin)
Node Exporter ⏩http://localhost:9100/metrics

Шаг 5. Настройка Grafana
Войти в Grafana.
Data Sources ➡️ добавить Prometheus (http://prometheus:9090).
Импортировать готовый дашборд (Node Exporter Full, ID: 1860).
Теперь у тебя полный обзор сервера: CPU, RAM, диски, сеть.


💡 Что дальше?
Подключить Alertmanager, чтобы слать уведомления в Telegram.
Добавить экспортёры для Postgres, Redis, Docker.
Настроить хранение метрик подольше (retention).

✅ Итог:

Node Exporter следит за сервером,
Prometheus собирает данные,
Grafana превращает их в графики.
И всё это — за 5 минут 🪐

#Prometheus #Grafana #Devops #monitoring