Существует много пособий по настройке программ (Операционок, сервисов, сайтов и тд), но редко можно встретить мануал по организационным вопросам связанным с системным администрированием. Сразу скажу, опыт работы у меня достаточный. Рассматриваться предмет будет на моем личном примере работы, сразу скажу что любые аргументированные дополнения, и исправления приветствуются. Также поясню для господ минусующих: «Не нравится? Сделай лучше!», и обязательно пришли ссылку, почитаю с большим удовольствием.

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

В последнее время в мировой компьютерной прессе стало появляться довольно много статей на тему: «Почему RAID-5 это плохо» (пример раз, два, и другие)

Постараюсь, без ныряния в инженерные и терминологические дебри объяснить, почему до сих пор RAID-5 вроде работал, а теперь вдруг перестал.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Отличный способ освоить Python — учебный класс Python в Google Code University. Уроки для этого класса написал Ник Парланте из Стэнфорда, и прошедшие курс люди отмечают не просто высокое, а фантастически высокое качество уроков.

Курс включает в себя шесть видеолекций на Youtube, где Ник проводит обучение новичков-гуглеров и подробно рассказывает о разных хитростях и фичах Python. Некоторые видеолекции длиной до 50 минут.

Есть ещё скачиваемые задачки. Они довольно простые и созданы специально для начинающих. Курс идеально подходит для изучения Python программистами, имеющими опыт работы с другими языками программирования.

Тематику cisco на хабре нельзя назвать популярной, зачастую интересные статьи остаются почти незамеченными. Но нас приятно удивил ажиотаж вокруг нашей предыдущей публикации. Больше тысячи человек добавили её в избранное, и это определённо говорит о том, что продолжение необходимо.
Кроме того, много людей, имеющих опыт реального планирования и строительства сетей, делали очень правильные замечания по резервированию. Дело в том, что предложенная в прошлый раз схема сети — это макет, лаборатория, на который мы будем отрабатывать и понимать технологии, поэтому такими вещами мы не озадачивались. В реальной же жизни, особенно, если вы оператор связи/провайдер, необходимы различные схемы резервирования: VRRP, STP, Link Aggregation, протоколы динамической маршрутизации.
Все замечания мы постараемся учесть и в конце цикла, вероятно, рассмотрим то, как сеть должна строиться, чтобы через полгода после запуска инженеру не было мучительно больно.

Сегодня же мы обратимся к части немного скучной, но важной для начинающих: как подключиться, поставить или сбросить пароль, войти по telnet. Также рассмотрим существующие программы — эмуляторы ciscо и интерфейс оборудования.
Как и обещали, в этот раз всё по-взрослому: с видео.

Под катом то же в текстовой и чуть более подробной форме.
Итак, вот они приехали — заветные коробки с надписью Cisco на борту.