O Di

Дисклеймер: я не системный архитектор, и даже не знаю, кто конкретно должен так называться, наверное это что-то вроде технического директора.

Или у меня чрезмерно идеалистические представления о роли архитекторов в разработке?

Да, чрезмерно. Архитекторы (как вы их называете) не боги и даже не "вторые после бога".

включая "подводные камни", которые, как правило, доступны только прилично поработавшим с технологией специалистам?

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

Опять же, отрасль очень бурная - когда успевать работать и следить за всем, что в ней происходит?

А надо уметь главное выделять. Ну к примеру, вот позавчера анонсировали докер на винде на нативных контейнерах. Что нужно знать хорошему техническому директору? Что в 2016-й винде есть контейнеры (причём двух видов, настоящие и поверх hyper-v), что докер теперь будет их использовать со всеми вытекающими. Само собой нужно представлять что такое контейнер и чем от отличается от ВМ. Вот и всё что нужно знать, ну и посматривать за отзывами первых, кто осмелится опробовать технологию в деле.

Ну или вот возьмём TypeScript. Не обязательно писать на нём или знать его досконально. Достаточно понимать, что такое статическая типизация в языке, и уже можно будет представить разницу между использованием в большом проекте ES5/ES6 и TypeScript. Достаточно принять решение опробовать его у себя (как сейчас делаем мы) на небольшом куске проекта, и сделать вывод о дальнейшем использовании.

Возьмём, наконец, базы данных. Не думаю, что хороший "архитектор" обязан знать, что в какой-нибудь Монге какие-нибудь запросы с агрегацией по двум свойствам работают в 5 раз медленнее, чем по одному свойству. Однако то, что в Монге нет атомарной записи сразу нескольких документов, знать очень полезно, я бы даже сказал, критично (иначе можно пытаться написать какой-нибудь биллинг на Монге вместо какой-нибудь реляционной базы, и сорвать пучок проблем).

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

• для каких задач подходят функциональные языки, а для каких - ОО;
  
• что графовая СУБД как правило быстрее обрабатывает запросы на поиск с большой длиной цепочки;
  
• что утверждение из предыдущего пункта неплохо бы проверить на практике с конкретными СУБД;
  
• что веб-фреймворки бывают толстые и тонкие;
  
• какие сегодня есть вариации паттерна MVC;
  
• что сборка мусора это всегда накладные расходы и иногда не вполне предсказуемое поведение;
  
• что данные от пользователя нужно фильтровать, иначе в вашей системе найдут машину Тьюринга не там, где надо;
  
• что в информационной системе есть компоненты с разным уровнем доверия, равно как и сотрудники;
  
• что транзакции в СУБД придумали не для того, чтобы учебники стали толще.
  

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

https://gist.github.com/
https://jsfiddle.net/

Разводилово...

DevOps расшифровывается как Development Operations.
В повседневные задачи DevOps инженера входит управление инфраструктурой приложений (в основном веб).
Что должен знать и уметь такой инженер - например по клику кнопкой в нужном датацентре произошел деплой приложения. DevOps должен суметь создать этот интерфейс с кнопкой и автоматизировать процесс приобретения инстанса (например в AWS), установки операционной системы и необходимых пакетов, доставки приложения на этот инстанс, прописывания всех настроек в приложении и приведение приложения в полную боевую готовность, т.е. состояние, в котором к приложению можно пускать пользователей.

По пунктам, что нужно знать и уметь:

• неистово учиться и гуглить
  
• сетевые технологии, на уровне маршрутизации, TCP/IP, DNS, SMTP и остальных протоколов начиная с 3 уровня модели OSI
  
• сетевые операционные системы (преимущественно семейства Linux) на уровне автоматизирования установки, обновления, настройки безопасности и мониторинга
  
• системы виртуализации (Xen, OpenVZ) и контейнеризации (Docker, Vagrant)
  
• настраивать сервера и мигрировать конфигурации, например перейти с Apache на Nginx, или с PHP на HHVM
  
• Chef
  
• Puppet
  
• Ansible
  
• Capistrano
  
• VCS
  
• AWS/OpWorks/CloudFormation/CodeDeploy, OpenStack
  
• Munin/Logstash/Kibana и другие связки для мониторинга
  
• Continuous delivery
  
• Программировать на Bash, Ruby, Python, Go, Perl, уметь понимать конфиги на самых экзотических языках, например YAML
  
• TDD
  
• продукты hashicorp
  
• автоматизировать создание и восстановление бэкапов баз данных
  
• масштабировать приложения по горизонтали (настраивать балансировщики, реверс-проксирование, шардинг и репликацию в базах)
  
• рассчитывать и оптимизировать издержки на поддержание инфраструктуры приложений
  
• видеть будущее инфраструктуры приложения и компании, двигать инфраструктуру в это будущее
  

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

How to create a restricted SSH user for port forwa...

загрузиться с live-cd и проверить?

И да, и нет. Все зависит от цели. Постараюсь объяснить.

Я уже как-то упоминал про тот факт, что люди воспринимают информацию по-разному. Мой приоритет - книги (а не аудио/видео, например). Мой подход к обучению - step-by-step, от простого к сложному, одна технология в фаворе. Но эта последовательность не линейна - на определенном этапе она становится цикличной, или, что точнее, спиралевидной: в пройденном, как тебе кажется, материале ты начинаешь замечать новые моменты, ранее упущенные из виду.

Пример:
я начинал с Доусона. Проработав капитально, взялся за Лутца. После - Fluent Python, Python Cookbook и иже с ними... (HTML, Django, CSS, работа над собственным проектом - это я все опускаю, как не относящиеся к сути вопроса детали. Говорим только про Python и книги.)

Так вот, к Доусону я больше не возвращался, к Лутцу - иногда возвращаюсь, а "иже с ними" я перечитываю по кругу и каждый раз открываю для себя что-то новое. Это, скорее всего, связано с тем, что всякий раз ты возвращаешься на исходную позицию с уже более прокачанными знаниями/пониманием, отстутствие которых не позволяет охватить все и сразу с первой попытки; плюс, каждый автор преподносит один и тот же материал с другой стороны (другими примерами), что дополнительно углубляет твое понимание пройденого.

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

Замечу, что все вышеописанное базируется на предположении, что вы стремитесь к максимальному развитию в рамках своей технологии. На мой взгляд, нельзя объять необъятное и хвататься за все сразу; step-by-step, как я говорил. Должна быть, по меньшей мере одна крепкая база + сопутствующее. Но эта база должна быть отшлифована до блеска, как птичьи плоды одного из небезызвестного персонажа из бронзы, расположеного на севере парка Боулинг-Грин в Финансовом квартале Нью-Йорка, в двух кварталах южнее Нью-Йоркской фондовой биржи.

Для меня такой базой, в настоящее время, является Python. Ему я и уделяю большую часть времени, распределяя оставшееся на Прочее. А вот когда я абсолютно и полностью исчерпаю Python - буду искать следующую Приоритетную цель на его место. И так далее. Процесс, фактически, бесконечен.

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

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

P.S. Про литературу в целом можете посмотреть ТУТ.

Имхо сейчас заббикс на голову выше нагиос.
по поводу чеклиста внедрения:
1. Читать доки
2. Установить.
3. Настроить то что "горит" или часто требует внимания
4. Разобраться с оповещениями (рулит оповещение в телеграмм https://github.com/ableev/Zabbix-in-Telegram )
5. Разобраться с lld (https://habrahabr.ru/company/zabbix/blog/193460/ )
6. Надыбать шаблонов (идеально с lld) под нужные системы, оборудование (share.zabbix.com и github.com)
7. Настроить прием snmp trap (если есть)
8. Понять что делать со свалившимся счастьем и куда ехать дальше (highload.guide/blog/support-highloaded-projects.html )
9. Интегрировать с grafana (https://github.com/alexanderzobnin/grafana-zabbix )
10. Повесить огромный телик на видном месте и залипать на красоту...(ну или выводить на него триггеры и карту сети + серверов :) )
11. Изучить API и либы к нему на знакомом языке
12. Написать свою систему мониторинга с преферансом и поэтессами (www.slideshare.net/profyclub_ru/i-git-in-sky )

Это обёртка SHOW FULL PROCESSLIST и частота опроса в ней больше чем время выполнения запросов.
включите логирование в my.cnf и используйте tail -f log.file

https://gist.github.com/

iotop
atop

Схема адресности не изменилась х32 будет работать до 4 гигов, х64 4+. Сама по себе 10 да и 8.1 работает как то резвее чем 7 хотя может быть самовнушение это.