понедельник, 11 апреля 2011 г.

В помощь начинающему программисту.

Ну что там обычно новичку советуют? Типа изучай си, нет си сложен, изучай паскаль... посмотри на php. О есть такая штука как питон. Нет, об этом я сегодня говорить не буду. И не буду сравнивать, ide и "блокнот". Сегодня я расскажу о важном и удобном инструменте

В общем ситуация с кодом такая, что если ты ценишь свой труд, то ты захочешь сохранить свой код. Тут спасают бэкапы  - это понятно. А что делать с кодом, когда с ним работают несколько человек? А что делать, если надо вести сразу несколько вариантов проекта? А как организовать совместную работу над проектом? Вот на эти вопросы многие ответа и не знают. Ну конечно можно обговорить все последовательности действий. Разработать четкую структура, кто в какой код лезет, но это обычно сложно и не очень продуктивно. Ну сами посудите, я пишу кусок кода, тут оказывается, что в Васином участке какой-то глюк, поправить я его не могу, только отослать Васе, Вася ругается, что правил Федя и он дурак. И не понятно в итоге, что толком делать. 

четверг, 7 апреля 2011 г.

Новичкам. Как упрощать себе админство или зачем нам мониторинг.

Побьют меня за мой язык, но скажу следующий тезис. Системный администратор - это высококвалифицированная(ый) уборщица(к). Т.е. это та должность которая непосредственно не влияет на функционирование проекта. К чему я это? А к тому, что на вверенной тебе территории ты должен знать что происходит, и уделять при этом как можно меньше сил. Это от того, что сделаешь ли ты на 5+ или  на 3-, никто в компании об этом не узнает, до момента когда всё не рухнет(т.е. станет совсем грязно - прим. уборщицы(ка)). Т.е. непосредственный твой начальник - это возглас работников "шо за нах(WTF)". Т.е. следить за всем приходится всегда тебе.
А что мы знаем о средствах слежения. Бинокль, радио метки, радарные комплексы... не чего-то они мне ни как не помогают. Следим мы по статусу WTF(см. выше). Т.к. 24 часа в сутки мониторить серваки не возможно, то кто-то это должен делать за тебя. Можно нанать пару китайцев или индусов (да именно так работают в крупных компаниях), но у нас бюджет. Да и время реакции в 15-30 минут не критично.

понедельник, 4 апреля 2011 г.

весть о lvm и snapshots

Часто делая бэкап я ловил себя на мысли: "Статику бэкапить одно удовольствие, а динамику - долго и беда". Ну правда, статический контент он по определению не очень меняется. А вот динамический стремится в любую секунду меняться по десятку, а то и сотне раз. И беда в том, что это как правило БД или почтовые ящики пользаков. И останавливать сервис на долго нельзя. Ну т.е. если на 3-4 минуты, нас с тобой никто не убьет (ну в общем всё зависит от того, чем занимаемся, на фондовой бирже так делать не стоит), а вот если на час или два ... в общем без комментариев.

Статику мы можем копировать, а вот с динамикой ... останови БД, скопируй, запусти. Вот как раз процесс копирования может быть очень долог. Что делать?