1. проводить friendly семинары в раскрепощенной обстановке с решением интересных и актуальных задач.
2. парное программирование/верстка
3. литературу и материалы сами в сети нужную найдут в большинстве случаев
4. контент-менеджерам и саппорту мануалы.
пы.сы. тестирование и аттестация имхо бред. на этапе приема сотрудника на работу вы уже должны определить — выстрелит ли он. не выстрелит — попрощаться. и лучший показатель — не тестирование, а продуктивность и качество работы.
Кто мешает через puppet хранить ключ в ~/.ssh/authorized_keys?
У нас так реализовано (правда через chef) — список пользователей, привязанный к ним список ключей и authorized_keys перезаписывается если список изменился.
Проблем никаких — ключ поменялся, ты изменил его для пользователя, изменение разошлось по серверам. Старые ключи при этом потерлись, чтобы был контроль над доступом.
не понятно, а зачем нужны активные элементы если ими нельзя воспользоваться, почему не сделать не активными все эти стрелочки и прочее. Какой-то недоделанный функционал получается
Есть еще варианты:
Специалист – Ведущий специалист – Эксперт.
Специалист – Ведущий специалист – Системный Архитектор.
Специалист – Ведущий специалист – Аналитик-консультант (настоящий)
Специалист – Ведущий специалист – Руководитель отдела — Начальник Управления — Директор Департамента — Член Правления
Специалист – Ведущий специалист – Владелец собственного бизнеса.
По всем этим трем у меня есть отличные примеры знакомых людей.
Первые три — получают на уровне (или больше) чем их руководители. Увлекательная работа на многие годы для тех, кому руководство не лежит к душе.
exec { "runmongo":
command =>"bash /etc/rc.d/rc.mongo",
path => "/usr/bin:/usr/sbin:/bin",
require => File["/etc/rc.d/rc.mongo"], <-- А вот эта запятая здесь не лишняя?
}
Возможно ещё поможет указание #!/bin/bash вначале скрипта…
В качестве свитчей можно смотреть HP Procurve 2510. Безотказные железки, удобные в управлении и значительно дешевле цисок. Правда в этом случае стоит вопрос совместимости по протоколам типа QoSов, но нерешаемых проблем нет.
Если позволит бюджет, то ставить два гейтвея и поднимать между ними VRRP, серверную ферму подключать к шлюзу через 2 свитча, резервирующих друг друга. Связь до всех важных узлов резервировать и настраивать маршрутизацию по ospf.
Не забудьте сразу описывать все кабеля, кабельную структуру, маркировку кабелей и портов и тщательное документирование. можно вести локальную медиавики + карты в visio/его аналоге. на стенках серверных шкафов — описание где какие вводы (чтобы сервер включать в разные вводы) где какие сервера и какой функционал они выполняют. тестовые лучше выделить в отдельный шкаф.
Кабели лучше вести заново — будете уверены что они новые, т.к. старые могут перебиваться и так далее.
БС (базовая станция) с биллингом напрямую не взаимодействует. Интегрируется биллинг с NSS (http://en.wikipedia.org/wiki/Network_switching_subsystem)
Стандартов куча (GSMA, etsi, 3gpp). Могу рассказать в деталях, но нужны конкретные вопросы.
Для начала почитайте статьи с pro-gsm.info/, там пишут правду простым языком.
