RaistlinMadjere

Статья, которую должен прочитать каждый.

DevOps - не профессия. Это название культуры доставки кода от разработчика (dev) через тестировщиков и до сисадмина(ops) и обратная связь по этой цепочке.

Человека, который внедряет DevOps, обычно называют... как хотят. Чаще всего этим занимается какой-нибудь нон-конформист в команде.

Профессии, которые отрисуются в процессе построения этой методологии следующие:

• Build Engineer - инженер, который управляет зависимостями, сборками, конфликтами кода.
• Release Engineer - инженер, который управляет репозиторием кода (кто куда и по каким правилам мерджится и откуда бренчуется). Пожалуй, это самая сложная задача в больших проектах. Особенно с нестрогим Agile или в Waterfall.
• Automation Engineer - инженер, который занимается автоматизацией рутинных задач. Обычно деплоймент, автотесты, etc. Все эти buzz-слова типа Docker - его инструментарий.
• Site Reliability Engineer - инженер, который поддерживает ops (апгрейды, расширение железа)
• Configuration Manager - непонятная мне специальность. Жуткое порождение HR-специалистов, давящих на громкое название позиции. Можно было бы пойти дальше и назвать специальность ZooKeeper Vice President
  

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

Почти всегда все эти роли совмещают один-два человека. Ну это зависит от качества кода.
Назовем эту компанию BRAE/CM для краткости.
Задача BRAE/CM состоит в том, чтобы программный код, который выходит из под пера программистов, оставался на контроле программистов и сисадминов одновременно. Программисты, равно как и сисадмины, благодаря DevOps-подходу, имеют возможность и даже обязаны обслуживать код на протяжении всего жизненного цикла от планирования архитектуры до мусорки.
То есть сисадмины начинают рулить еще до того, как код попадет к ним - на ранних стадиях, а программисты продолжают рулить своими задачами уже после того, как код от них ушел к сисадминам - на поздних стадиях. И все это прозрачно друг для друга и все проблемы и решения ходят туда сюда и не спотыкаются о бюрократия в стиле "ничего не знаю, мы код уже закоммитили, у меня тут свои проблемы, у них сломалось - пусть сами и чинят".

Так вот эта работа - завершающая стадия системного администратора и начинающая стадия разработчика. Поэтому не бывает Junior BRAE/CM.
BRAE/CM бывает всегда только Senior в системном администрировании и всегда Junior в программировании.

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

Сразу оговорюсь по языкам.
У каждого языка свое предназначение. Java чаще используется в корпоративном секторе. Там много серверов и сложные бизнес-приложения. Поэтому Java-мир очень чувствителен к таким понятиям, как "технинческий долг" и "управление процессом разработки". И именно поэтому именно там все основные вакансии DevOps и именно там будет самый интересный опыт.
Кроме Java, традиционно сильная DevOps-культура у Ruby. Практически все остальные языки не имеют столь развитой и популярной инфраструктуры в в данном контексте и потому вам скорее всего будут неинтересны.
Другими словами, если в среде разработчиков выбор языка - тема для холивара и эмоций с миллионами сравнительных анализов с противоположными результатами, то для специалистов по DevOps выбор очевиден и прозрачен. Java - это одновременно самые интересные задачи, самый богатый toolset, самый большой выбор вакансий и самые высокие зарплаты.

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

Итак, что делать:
1) Почитать книги Head First по Java. Пройти курсы Java на EDX.
2) Освоить SVN. Есть прекрасные тьюториалы. (GIT освоим позже)
3) Поставить VirtualBox (не VMWare!!!)
4) Написать простенькое приложение. Код коммитить в SVN. Собирать его при помощи maven.
5) Поднять на отдельной виртуалке Jenkins. Он должен брать код приложения на SVN и запускать свой локальный maven для сборки.
6) Написать модульные тесты (unit tests) своего кода. Пусть maven и их прогоняет.
7) Поднять где-нибудь Nexus. Усложнить задачу maven, чтобы он теперь складывал все в Nexus. Если maven'у потребуются внешние библиотеки, он тоже не сам должен ходить в интернет, а через Nexus (Central repo).
8) Настроить на своем десктопе vagrant так, чтобы он с нуля создавал виртуалки VirtualBox.
9) Создать виртуалку DEV через vagrant. При этом ansible должен на ней что-нибудь настроить (например установить JDK)
10) Научиться деплоить jar/war из Nexus на виртуалку DEV чем-нибудь. Чем - не посоветую, так как сам работаю с очень сложным IBM uDeploy, а это точно не для новичка. Посмотрите в сторону Rundeck или чего-то такого. Может самим Jenkins'ом задеплойте.
11) Напишите интеграционные АВТОтесты. На чем хотите (как вариант: Selenium).

Усложняем систему.
12) Донастраиваем Jenkins: собирает maven-проект; выкладывает на Nexus; дергает vagrant/ansible для создания виртуалки SIT (system integration test); деплоит приложение на SIT; прогоняет автотесты на SIT; удаляет виртуалку после успешного завершения автотестов.
13) Прикручиваем SonarQube в Jenkins для статического анализа кода. Исправляем косяки своего кода, согласно полученным от SQ рекомендациям.
14) Прикручиваем мониторинг Sensu.
15) Пишем нагрузочные тесты на чем-нибудь. В идеале потрогать два инструмента: jMeter и Gatling.
16) Как и в 12-м шаге прикручиваем в Jenkins автоматизацию создания виртуалки SLT (Stress/Load test) и прогона на ней тестов. Только уже лоад-тестов(обязательно) и стресс-тестов(опционально) соответственно.
17) Дописываем в свое приложение какой-нибудь функционал, чтобы использовалась база.
18) Придется познакомиться с LiquiBase. Деплой SQL руками делать запрещено.
19) Перейти на Docker (то есть теперь приложение выкладывать не напрямую в ОС, а внутрь докера)

20) Денек на то, чтобы почитать про Agile, Scrum, Waterfall и прочие организационные порядки.

А теперь немного уходим в управление проектом:
21) Поставить Atlassian Jira. Разобраться, чем отличаются Epic, Story, Task, Sub-Task. Создать себе подобной этой структуре фронт работ (делать его не придется, просто нафантазируйте).
22) Поставить Atlassian Stash и связать его с Jira.
23) Переехать со своего SVN на GIT, предоставленный Stash'ем.
24) Пройти Git-тьюториал какой-нибудь. Инструмент очень нетривиальный.
25) Взять любую таску в работу. При этом в начале работы сделать новый Git branch из тикета Jira.
26) По завершению работы запустить всю построенную ранее цепочку, но уже для своего брэнча.
Дайте попробую угадать: вам пришлось скопировать все джобы и переписывать в них ветки?
27) Сделать джобы нормально. Чтобы одни и те же можно было использовать для любых веток - по аналогии с принципом программирования "reuse code". У Вас будет reuse job :)
28) Сделать pull request, самому сделать code review и самому себя же за-approve'ить. После этого сделать merge своей ветки в master.
29) Сделать сборку брэнча автоматической по git-hook (или SCM pool)

30) А теперь высший пилотаж: к чертям Docker, Copistrano и прочую buzz-word-hipsters-галиматью. Теперь вы с этим знакомы и сможете применить, но пришло время выгрызать этот детский сад калёным железом. Теперь вы доставляете код только как .deb-пакеты. Это значит, что вы:
a) разбиваете control-файл на несколько пакетов, возможно с lib*,
b) оверрайдите все ~20 dh_ в файле rules так, чтобы все это соответствовало вашим наработкам в предыдущих пунктах.
c) раскидываете файлы по .install
d) самое тяжелое: готовите .preinst, .postinst, .prerm, .postrm файлы СОГЛАСНО ИХ ПРИМЕРАМ .ex, сгенерированным dh_make - то есть с разбиемнием на update/configure/broken-install и что там еще есть. Это означает, что при переустановке, при апгрейде, при даунгрейде, при удалении и при пурдже, у вас будут разные сценарии, каждый из которых должен быть проработан досканально. На этом этапе вы также познакомитесь с понятием "регрессионные тесты".

Ну как бы базовый вариант вот. Но это далеко не весь инструментарий и путь. Это так, для начала.
Кроме этого неплохо бы познакомиться с Puppet (это не очень подходит для DevOps, скорее для рядовых админов с кучей серверов, но это очень популярный инструмент ввиду того, что никто не понимает, что такое DevOps и вас скорее всего заставят управлять сотней серверов, вместо релиз инжиниринга). А так же нужно познакомиться с операционными системами NixOS (обязательно) и CentOS/Debian (опционально, но я бы палкой бил тех, кто не знает эти OS). Кроме того, надо базово ориентирваться в PostgreSQL.

Внимание, важный момент, который должен быть вшит на уровень подсознания у DevOps-ориентированного инженера: вы все время пробуете новые инструменты. Вы всегда будете находить что-то очень отличное. Знаете Nexus как свои пять пальцев и он решает почти все проблемы? Отлично! Теперь выкидываете Nexus и ставите Artifactory. Знаете хорошо CentOS? Круто! Теперь пробуете все это проделать на Windows или Debian. Потому что только когда вы сможете сравнивать инструменты, ваша работа будет ювелирной. А DevOps бывает либо ювелирным, либо он не DevOps. Вы должны быть языко-независимым, платформо-независимым и инструменто-независимым.

Что будет дальше? Дальше вы начнете работать с микросервисами (сотни одинаковых контейнеров в облаке, которые должны как-то работать друг с другом без ручной конфигурации). Тогда познакомитесь со всякими Consul, ZooKepper и кучей инструментов AWS/OpenStack.

Поместив HTML, XML, SVG и т.д. и т.п. файл на домене usercontent.google.com можно
манипулировать куками домена google.com и фишить. Поэтому пользовательский контент всегда отдается с отдельных sandbox-доменов.
Так же с отдельных доменов обычно отдается статический контент, это позволяет использовать CDN и упрощает управление кэшированием.
Отдельный домен обычно используется для PTR-записей (например 1e100.net). Для PTR часто нужна двойная валидация, т.е. PTR должна разрешаться в имя и имя обратно в тот же IP. При этом на одном IP может хоститься много доменов и быть установлено много сертификатов, включая вайлдкарды. И наоборот, один домен может хоститься на многих IP. Чтобы исключить прямое обращение к хосту по "неожиданному" для него имени в своем домене, обычно используются PTR записи в нейтральном домене. Кстати исторически принято использовать именно домены в .net. Google так же использует 1e100.net как нейтральный домен для подписи транзитных писем, раньше для этого использовался собственно домен google.com и это приводило к забавному багу, позволявшему подделывать подписи на письмах от google.com, я рассказывал о нем на PHDays 2014.
Географические домены исторически используют для организации региональных датацентов и ускорения доступа, например yahoo.jp физически расположен в Японии.

заниматься только ИТ, администрировать крутые проекты

УСТРОИТЬСЯ в 2-3 компании для работы по удаленке

утверждения, не то, чтобы противоречащие друг другу, но скажем так - ортогональные :) Крутые проекты бывают только в крупных компаниях, потому что они требуют денег, денег и еще раз денег. А это опять же корпоративные политики, регламенты, приказы... Зато будет только ИТ. Если же мутите свой бизнес - придется заниматься зиллоном "параллельных" тем - от бухучета до рекламы.

Если хотите без регламентов и корпоративных политик - открывайте свое дело. Но там крутых проектов не будет - по крайней мере поначалу. А будут все те же корпоративные сети, только вид сбоку, общение через ТЗ. Крупным компаниям интересен только админ на фуллтайм, никаких удаленок они обычно не рассматривают.

А теперь ответы
1. Таким, у которых нет денег на админа или же экономят на админе. Удаленка - это нечто вроде спаренного телефона в СССР, когда пары телефонные не в каждую квартиру заходили. Уровень проектов там будет соответствующий. Уровень заказчика - тоже. Фраза "я довела мышь до края коврика, что теперь делать"? - анекодт, но взят из жизни :)
2. Сотрудничают с равным. Если мутите свой бизнес, то зависит от того, какую. репутацию наберете. Если нет - какое сотрудничество?
3. Так же как и везде - полно.
4. Если мутите свой бизнес - читайте про PR. Если нет - про то, как общаться с потенциальным работодателем
5. В крупной конторе, где можно рассчитывать на "крутые проекты" - это единственный способ трудоустройства. Если мутите свой бизнес - Вы сами себя трудоустроили :)

Я Вас некоторым образом понимаю. Сам в таком положении был лет...эээ...десять назад. Но, если хотите заниматься "только ИТ", это означает, что есть другие люди, которые занимаются другими вещами - расчетом Вашей зарплаты, планированием закупок, оформлением трудовых книжек, перевозкой товара etc. А это может быть только в крупной компании. Открыв же свой бизнес, Вы избавляетесь от проблем, характерных для крупных компаний, но "чистого ИТ" уже не будет - хотите или не хотите, а придется заниматься бухучетом (или нанять), финансовым планированием (или нанять), рекламой и продвижением (или нанять), арендой офиса (или нанять). А если будете кого-то нанимать - это автоматически тащит за собой оформление трудовых договоров (или нанять)...

Мягкое кресло и на все согласная секретарша БигБоссу вовсе не за просто так даются бонусом... :)

Верно ли, что занести на свой компьютер вирус невозможно при серфинге по сомнительным сайтам?

возможно.

Один из вариантов т.н. "связки".
Как правило их сдают в аренду за некоторое количество тысяч долларов.
У них есть набор браузеров которые они "пробивают".
Пробив - установка/запуск вредоносного кода на компьютере жертвы.

Суть связки - набор эксплоитов для обхода всевозможных систем безопасности и окружения браузера т.е. с помощью разных дыр пролезают в систему. Естественно все это делается автоматически и дыры используются в зависимости от браузера в котором загрузился сайт с кодом вредоносным.
В хроме например через дыру флеш плеера загрузится.
В IE через дыру в JAVA
и т.д.

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

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

Верно, но при ооооочень большом списке оговорок.

- Это Firefox
- В нем установлены AdBlock, NoScript, BetterPrivacy, Blur и еще все какие-только-можно-придумать плагины
- Пользователь не лезет в настройки. Вообще.
- Пользователь не ставит плагинов, не меняет тем, вообще ничего не делает с браузером, только закладки сохраняет
- Пользователь внимательно читает то, что ему показывают и при малейшем подозрении зовет админа или более продвинутого пользователя

И то, стопроцентной гарантии я бы не дал.

Друг.
Тебе много ответили про самообучение и это правильно.
Расскажу свою историю, а ты уже думай сам.
Я начинал с 12 лет, когда меня классная руководитель отправила в кружок(когда это так называлось) информатики. там нас учили программировать на паскале(год был 1993-й). Все кто со мной ходили, ходили ради поиграть в конце, однако меня игры не интересовали, да и не об этом.
На следующий год я пошел в Городской Научное Общество Учащихся(ГНОУ) при кафедре информатики и программирования МИФИ-2. Прозанимался положенных 4 года, набрался знаний и опыта программирования.
Потом так случилось, что не было возможности продолжать и я на это дело забил до 2001 года. Тогда у нас в городе только стал появляться интернет. Поставил себе комп, подключил Dial-Up. зал какое-то время, потом появилась выделенка, но с оплатой за трафик. К тому времени я разжился еще один системником. Сговорился с соседями, чтобы покупать большой объем трафика и соответственно платить за него поменьше. Нужно было поставить сервер, лучше прокси, для экономии трафика, и так же нужно было считать этот трафик, чтобы предъявлять счет каждому из соседей с отчетностью где и что делали.
Так был изучен Windows NT 4, потом Windows server 2000, потом 2003. Потом попробовал готовое решение на Linux, понравилось. Посоветовавшись с уже знакомыми админами и со своим другом админом, стал юзать Linux. начал с ASP Linux. "игрушка" та еще, скажу я вам, но все же. Потом был CentOS. И так наступил 2007 или 2008 год. Слышал много об FreeBSD, но ничего у меня не получалось с ним, потом я где-то наткнулся на бесплатный биллинг nodeny, который работает только на FreeBSD.
Да, к этому времени уже безлимитки появились;)
В общем поставил NoDeny и в горем пополам запустил. Начал изучать что да как. Пытаться запускать веб-сервисы, почту и прочее. В 2008 году купил домен(с которым по сей день не расстаюсь), сделал почту. Статей было мало еще и разбирался сам. Так наступил 2009 год, появилась мысль открыть некоммерческую структуру, предоставляющую всем желающим интернет, но за членские взносы. Так начался новый виток. на моменте запуска проекта уже в эксплуатацию, наш "мозг" слился и все заткнулось. осталось железо, которое досталось мне. В итоге я начал на этом железе мастерить все, что только приходило в голову.
По итогу всех этих изучений, я добрался того, что устроился сначала на работу приходящим админом в небольшую компанию, где шлюз и почта вертелись на FreeBSD, домен на Windows Server 2008, а еще на одном серваке вертелся MS SQL. Так началось мое знакомство и со скулем. Через полтора года я устроился в веб-студию админом, где хост-сервер на колокейшн, в офисе сервера разработки, шлюз, почта на FreeBSD, виндовые сервисы конечно на винде. Мое резюме висело на сайте трудоустройства и меня пригласили работать к провайдеру. Я с радостью пошел, но вскоре ушел из-за того, что до работы добираться 2 часа по городу. Это был атас.
После этого, я подрабатывал в такси, хватал фрилансные заказы.
Так наступил 2012 год. Я на бум отправил резюме в рекламную компанию и неожиданно для меня, спустя месяц, пригласили на собеседование. Пообщались и распрощались. Через пару недель ни ответа ни привета и спустя еще месяц меня пригласили на контрольное собеседование, на котором мне сказали что хотят меня взять, но предъявили определенные условия, с которыми я согласился.
Я к тому времени в режиме самоучки набрался порядком опыта и мог очень многое, не пользуясь практически интернетом.
Через месяц сдохло железо на работе и я поднимал все сервера по очереди с нуля. Я неделю жил на работе, но в итоге я все сделал с нуля и сам. Получил несколько сервер на FreeBSD, один на RHEL 6.3, и несколько на Windows server 2008 и 2008R2.
Работая в большой компании с нагрузкой в 120%, один админ на всех, включая удаленные офисы(челябинск, москва, питер, новосибирск). Так прошло еще 3 года и в том году, меня пригласила в новую компанию, которая решила собрать под одним брендом примерно десяток разных компаний и обозвались Группа Компаний, чтобы без рекламы назовем "Рога и копыта". Пригласили меня сначала на роль сисадмина с перспективой роста до руководителя отдела. Через пол года я стал руководителем отдела и не просто отдельчика, а "Отдела IT сопровождения группы компаний", а это, на минуточку, уже полтора десятка внутренних компаний и плюс десятка два внешний клиентов по направлению IT-аутсорсинга.
Сейчас у меня есть подчиненные, эникейщики, такие как ты сейчас. Я очень строг, но благодаря этому я воспитываю в сотрудниках ответственность и желание стремиться к большему. Они у меня учатся, учатся сами, потому что никто кроме них самих их учить не будет.
Знаешь как учили плавать детей?! Вот я и так же. Отправляю к клиенту или на объект и даю ему все, а именно интернет и его соображалку для решения поставленных задач. Да, они ошибаются, но это нормально. Я не ругаю, я просто отправляю переделывать объясняя почему не нужно было именно так делать и почему нужно сделать иначе.

Делай выводы сам.
Только от тебя зависит то, каких высот ты добъешься. Я не претендую на звание "Лучший админ", нет. Я очень многого не знаю, я сам порой задаю тут вопросы и мне на них отвечают более компетентные в этом вопросе люди.
Так что...

Правильно тебе советуют. Возьми комп, поставь на него виртуалку и трестируй. Создавай импровизированные сети с серверами, создавай проблемы или попроси знакомых их создать и разрешай их. начни изучать VPN, VLAN, активное сетевое оборудование.
У меня сейчас личных две интеловские серверные платформы, на одной собрана виртуализация на основе KVM, на второй Hyper-V Server 2016.
Не первой вертится *NIX-овое добро, на Hyper-V Виндовое.
WMVare не ставил, т.к. не поддерживается железо и всего-то.
P.S. В 2009 году, когда я уже активно изучал хрюшу(FreeBSD), я пересел с винды на Ubuntu. Сначала на 9-ю ветку, потом на 10-ю, потом на 12-ю, а после 12-й ветки купил ноут, железо которого частично поддерживает OS X. Так я поставил себе Мак и до сих пор работаю на маке. Сейчас у меня 2 Ноутбука, HP ProBook 47-я серия, и Toshiba Sattelite, тоже 17", на обоих OS X. На домашнем компе - OS X(Core2Quad, в последствии Xeon 5460). На работе тоже стоит OS X.

P.P.S. Сейчас перечитал, проверил что написал.... Ну и поэму настрочил :-D

Если кому-то еще нужно, вот решение
Проверялось на windows 8-8.1

1)получится с таким же контроллером
2) не соберется, один из диском будет главным и на нем будет работать система, второй диск пометится как деграйдед