#devops #советы_для_джунов

Чем отличается джун от синьора. Советы для джунов.

1. Эффективно работайте над задачами. Для каждой задачи вы должны
обозначить конечный результат и двигаться именно к этому результату.
Если задача не предполагает конечного результата, а например нужно сделать
инвестигейшн и выбрать нужный инструмент для работы, то все равно
должна быть понятная цель.

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

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


4. Автоматизация всего и вся. Ну тут как бы понятно, особенно тем кто работал
сисадмином=) Любые таски, любые работы с конфигами автоматизируйте, чтоб не пришлосьпотом опять делать руками. Например, надо развернуть QA окружение в клауде - можно сделатьза полчаса-час вручную, а можно сделать пайплайн, который автоматом все развернет. Потом будете реюзать его для всего остального. А если иногда кажется, что можно один раз сделать ионо больше не пригодится, то это иллюзия - потом все может пригодится.

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

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

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

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

9. Изучайте другие области и технологии
Проще говоря, развивайтесь всесторонне. Даже если вы devops инженер и пишите немного кода, то попробуйте изучить ООП или другие языки программирования. Если есть пробелы в других областях, то необходимо тоже все это подтягивать по мере сил и времени. Можно еще выучить дополнительно язык -
хорошо знаете английский, то попробуйте выучить немецкий, например. Ну и больше читайте, не только техническую литературу, но и всякие полезные книги по менеджменту и так далее.

10. И помните, что джун это тот, кто гуглит. Синьор это тот, кто уже давно все нагуглил))

#вопросы_на_собеседовании #devops_interview

Частый вопрос, кстати, на собеседованиях "Сервер А не может достучаться до сервера Б, назовите возможные причины"
Часто правильного ответа нет, этот вопрос - проверка на умение траблшутить проблему.
Причин может быть много и для начала, надо разобрать их на уровни взаимодействия.
Для этого еще необходимо вспомнить модель OSI.

Начнем с Application layer. Возможно сервер настроен неправильно, а возможно на нем kernel panic и он недоступен.
Если с софтом и ОС все в порядке, то переходим просто на уровень ниже.

Transport layer. Проверяем порты, сокеты, убеждаемся что нужное приложение слушает нужный порт.
Так же можно проверить, что сервер пингует сам себя и что со стеком TCP/IP все в порядке.
И если все ок, то переходим на уровень ниже.

Network layer. Частые проблемы на этом уровне. Проверяем firewall, dns, рутинг, так же arp и сетевые настройки.

P.S. Ну еще причиной может быть физический уровень - то есть сервак может быть просто выключен и отключен сетевой кабель.

#Devops #roadmap

Статья для тех, кто делает первые шаги в направлении Devops

https://dou.ua/lenta/articles/devops-dou-webinar/?from=recent

​​CI/CD best practices — AWS Whitepaper «Practicing Continuous Integration and Continuous Delivery on AWS»:

https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html

90% рекомендаций не привязаны к AWS, потому полезны для подавляющего большинства проектов/команд.

👍Do:
▪️ Treat your infrastructure as code
▫️▪️ Use version control for your infrastructure code.
▫️▪️ Make use of bug tracking/ticketing systems.
▫️▪️ Have peers review changes before applying them.
▫️▪️ Establish infrastructure code patterns/designs.
▫️▪️ Test infrastructure changes like code changes.
▪️ Put developers into integrated teams of no more than 12 self-sustaining members.
▪️ Have all developers commit code to the main trunk frequently, with no long-running feature branches.
▪️ Consistently adopt a build system such as Maven or Gradle across your organization and standardize builds.
▪️ Have developers build unit tests toward 100% coverage of the code base.
▪️ Ensure that unit tests are 70% of the overall testing in duration, number, and scope.
▪️ Ensure that unit tests are up-to-date and not neglected. Unit test failures should be fixed, not bypassed.
▪️ Treat your continuous delivery configuration as code.
▪️ Establish role-based security controls (that is, who can do what and when).
▫️▪️ Monitor/track every resource possible.
▫️▪️ Alert on services, availability, and response times.
▫️▪️ Capture, learn, and improve.
▫️▪️ Share access with everyone on the team.
▫️▪️ Plan metrics and monitoring into the lifecycle.
▪️ Keep and track standard metrics.
▫️▪️ Number of builds.
▫️▪️ Number of deployments.
▫️▪️ Average time for changes to reach production.
▫️▪️ Average time from first pipeline stage to each stage.
▫️▪️ Number of changes reaching production.
▫️▪️ Average build time.
▪️ Use multiple distinct pipelines for each branch and team.

👎Don’t:
▪️ Have long-running branches with large complicated merges.
▪️ Have manual tests.
▪️ Have manual approval processes, gates, code reviews, and security reviews.


#devops #dest_practices

🧪 Terraform тестування: що, навіщо і як?

Infrastructure as Code — це круто, але навіть найкращий код потребує тестів. Так само і з Terraform.

💥 Навіщо тестувати Terraform-код?

Перевірка синтаксису та логіки
Запобігання помилкам у продакшені
Валідація змін до merge в main

🔧 Які бувають типи тестів?

Linting & форматування – terraform fmt, tflint
Юніт-тести – terraform validate, terraform plan, checkov, tfsec
Інтеграційні тести – Terratest (на Go), Kitchen-Terraform, Test Kitchen
Policy as Code – OPA, Sentinel (якщо ви з HashiCorp Cloud)

📦 CI/CD інтеграція
Тести можна (і треба) запускати в GitHub Actions, GitLab CI, Jenkins, CircleCI – де завгодно, аби автоматично й на кожен PR.

🔥 Корисні інструменти:

tflint — статичний аналізатор для Terraform
checkov — безпека IaC
terratest — повноцінні інфраструктурні тести (Go)
tfsec — ще одна перевірка безпеки

#terraform #devops #iac #testing #інфраструктура #безпека #terraformtesting