Comments 83
Как страшно и сложно быть админом:
> Да, свободного времени больше у вас нет и не будет в ближайший год.
> вы теперь отвечаете за всё, что происходит с компьютерами.
> Роскошь уходить с работы во-время для вас будет закрыта на ближайшие пару лет
> Да, свободного времени больше у вас нет и не будет в ближайший год.
> вы теперь отвечаете за всё, что происходит с компьютерами.
> Роскошь уходить с работы во-время для вас будет закрыта на ближайшие пару лет
Ну просто есть эникейщики, считающие себя «админами», примерно как для тетушек из бухгалтерии все они — «программисты».
Таким «админом» быть не сложно, но речь все же не об этом.
Таким «админом» быть не сложно, но речь все же не об этом.
Да, лучше всего получать больше, а работать меньше. Но не интереснее.
Ну как сказать, «страшно и сложно». Начинающим админом быть страшно и сложно. Как практически любым начинающим. А дальше все чудесатее и чудесатее :)
У меня есть глубокое подозрение, что у врача, внезапно перешедшего в реанимацию для новорождённых, будет примерно так же.
У хорошего врача, я имею в виду.
У хорошего врача, я имею в виду.
Вставьте пожалуйста ссылки на предыдущие две части.
>Роскошь уходить с работы во-время для вас будет закрыта на ближайшие пару лет.
На прошлой работе уходил около 9-10 вечера, но мне позволяли и приходить «ну как проснешься». на крайний случай — удаленка ко всей сети. А критикалов, как правило и не было. Но было дело и ночевал и выходные убивал. Все равно работа душевная это. Меня все любили там :)))))
На прошлой работе уходил около 9-10 вечера, но мне позволяли и приходить «ну как проснешься». на крайний случай — удаленка ко всей сети. А критикалов, как правило и не было. Но было дело и ночевал и выходные убивал. Все равно работа душевная это. Меня все любили там :)))))
А у меня уже на второй работе проблемы с тем, что ухожу позже (а порой и существенно позже), но вот приходить «как проснешься» не дают ;) И даже пытались выговоры писать за опоздания, но эту проблему я уладил.
Ну а любят — да, когда у пользователей все работает, они тебя любят. За исключением «очень личной неприязни». Ну это когда в том, что инет перекрыт винят тебя, а не того, кто велел его перекрыть. Но это отдельная, клиническая история ;)
Ну а любят — да, когда у пользователей все работает, они тебя любят. За исключением «очень личной неприязни». Ну это когда в том, что инет перекрыт винят тебя, а не того, кто велел его перекрыть. Но это отдельная, клиническая история ;)
Любимое дело «Навести порядок в кроссе на 150 человек, логически распределив их по группам (16 дырок на бухгалтерию, 4 дырки на ресепшен, 8 дырок на безопасников) в субботу и распихать их по вланам
У нас на предприятии запрещено задерживаться более, чем на полтора часа. Так что все манипуляции я должен выполнять за этот короткий срок.
А если нужно произвести какой апдейт с остановкой сервисов? В рабочее время не айс.
Смысл? И речь не про манипуляции, а про обучение.
Я работал в похожей конторе, задерживаться было запрещено чтобы не платить сверхурочные и переработку.
Если нужно работать внерабочее время надо было писать служебку и подписывать у генерального. Причем могли и не подписать.
Если нужно работать внерабочее время надо было писать служебку и подписывать у генерального. Причем могли и не подписать.
Значит, надо дома заниматься. Но там расслабляет и отвлекает.
Я уже больше года из дома работаю (linux admin). Не особо расслабляет, но дитё отвлекает, это да.
Это от человека зависит. Я точно знаю, что дома (за вычетом внезапных всплесков интереса) КПД ниже, чем на работе.
Но у меня сейчас несколько иной график работы, в котором нет «сижу и ничего не делаю». Админить (в смысле, держать в порядке) да, можно и из дома.
Но у меня сейчас несколько иной график работы, в котором нет «сижу и ничего не делаю». Админить (в смысле, держать в порядке) да, можно и из дома.
Ну кончено всё зависит от человека, в офисе КПД тоже не 100% далеко.
В офисе можно ходить курить черте куда, зависая в курилке по полчаса, обедать в соседний ресторан, трепаться с коллегами о том «как наши кривоногие сыграли».
Читать вот дома я не могу :( готовлюсь к RHCE, для этого уезжаю на коворкинг. Или когда нужно максимально быстро засетапить десаток разномастных серверов.
В офисе можно ходить курить черте куда, зависая в курилке по полчаса, обедать в соседний ресторан, трепаться с коллегами о том «как наши кривоногие сыграли».
Читать вот дома я не могу :( готовлюсь к RHCE, для этого уезжаю на коворкинг. Или когда нужно максимально быстро засетапить десаток разномастных серверов.
> Ничего не меняйте просто так. Работает — не трогай. Пока вы не перерастёте сложность конфигурации, ломать её нельзя. Это вам должны подсказывать инстинкты. Если такого инстинкта нет — вы ошиблись профессией.
Абсолютно согласен. Лучше сначала сделай 3 бэкапа и эмуляцию, и все равно не ставь эксперименты на главной системе. И инстинкт этот… параноидальный очень важен. Последнее время начинаю замечать за собой буквально «рабочую паранойю» — постоянно боишься изменений, не подкрепленных несколькими дампами. А почему? А потому, что пока твоя система строится и тестируется с тебя и спроса никакого, как только все поработает пол года — так и любая заминка смерти подобна. Привыкают сотрудники к работоспособности и надежности системы.
Абсолютно согласен. Лучше сначала сделай 3 бэкапа и эмуляцию, и все равно не ставь эксперименты на главной системе. И инстинкт этот… параноидальный очень важен. Последнее время начинаю замечать за собой буквально «рабочую паранойю» — постоянно боишься изменений, не подкрепленных несколькими дампами. А почему? А потому, что пока твоя система строится и тестируется с тебя и спроса никакого, как только все поработает пол года — так и любая заминка смерти подобна. Привыкают сотрудники к работоспособности и надежности системы.
UFO just landed and posted this here
Есть пара «знакомых знакомых», которые стали торговать всяким специализированным софтом. Сначала немного пренебрежительно относились, но после того как один переехал в Европу, а другой в Азию и ходить в тысячедолларовых часах («да у нас такой дресс-код неформальный, если придёшь не в таких, то лох»), как-то быстро перестали. Так шта…
Суммы на сайте госзакупок кагбе говорят об обратном
UFO just landed and posted this here
Рядовым сотрудникам никто и никогда не даст более-менее серьезных денег. А если дорасти хотя бы до нач отедла…
Системное администрирование — это труд по технической эксплуатации.
Нужный конечно для компании, но прибыли не приносящий. Та же ступень, что и электрик, сантехник, лифтер.
Админ не должен быть гением, ему не надо проектировать сложные системы, он должен быть кропотливым, аккуратным и т.д. Ну и денег много он вряд ли будет получать.
Нужный конечно для компании, но прибыли не приносящий. Та же ступень, что и электрик, сантехник, лифтер.
Админ не должен быть гением, ему не надо проектировать сложные системы, он должен быть кропотливым, аккуратным и т.д. Ну и денег много он вряд ли будет получать.
Вот тут вы подходите к следующей моей теме — есть администраторы профильные, а есть непрофильные. Непрофильный администратор — это электрик. Нужно, чтобы был свет, но этот свет денег не приносит. Профильный администратор — это энергетик на электростанции. То, что он делает — приносит деньги компании.
Моё личное ИМХО — именно второе является важным шагом в карьере — шаг от обслуживающего персонала к создателю.
Моё личное ИМХО — именно второе является важным шагом в карьере — шаг от обслуживающего персонала к создателю.
Совершенно неверное разделение. Дело вовсе не в администраторе, как он может быть профильным или нет? Дело в конкретном бизнесе, на сколько он является зависящем от it. Понятно, что хостинг 100% завязан на it, а вот со всеми остальными случаями все очень индивидуально.
Простой пример из личного опыта — две крупные торговые сети, в одной it не нужно вообще, все делается по старинке, разве что в бухгалтерии 1с поддерживать эникей нужен, в другой все пордажи, кассы, завязаны на на общую базу, в случае сбоя почти все остановится, по этому it развито как никакой другой отдел, толстые каналы и продолжена собственная оптика по городу. А для внешнего наблюдателя обе фирмы выглядят почти одинаково.
Простой пример из личного опыта — две крупные торговые сети, в одной it не нужно вообще, все делается по старинке, разве что в бухгалтерии 1с поддерживать эникей нужен, в другой все пордажи, кассы, завязаны на на общую базу, в случае сбоя почти все остановится, по этому it развито как никакой другой отдел, толстые каналы и продолжена собственная оптика по городу. А для внешнего наблюдателя обе фирмы выглядят почти одинаково.
Ну, мы этот вопрос обсуждали уже.
Ключевым является то, что именно делает администратор — планирует развитие сервисов или их обслуживает. В компании определённого уровня это будет малая работа, а дальше «пыль сдувать». В быстро развивающихся компаниях и завязанных на ИТ эта работа постоянная. Собственно, соотношение между рутиной и творчеством определяет тип администратора.
Ключевым является то, что именно делает администратор — планирует развитие сервисов или их обслуживает. В компании определённого уровня это будет малая работа, а дальше «пыль сдувать». В быстро развивающихся компаниях и завязанных на ИТ эта работа постоянная. Собственно, соотношение между рутиной и творчеством определяет тип администратора.
Ну так бизнес-задачи определяют степень нужности инфраструктуры, а следовательно и их администрирование. Не надо говорить, что это администратор профильный.
А администратор в любом случае и планирует, и внедряет, и обслуживает. Иначе это хелпдеск или саппорт, но ни разу не администратор информационных систем.
А администратор в любом случае и планирует, и внедряет, и обслуживает. Иначе это хелпдеск или саппорт, но ни разу не администратор информационных систем.
Я немного не о том. Вот взять взгромоздить сервер по best practicie от вендора решения, поставить туда от другого вендора по тем же best practicie софтовую часть, иметь сертификат по администрированию и обслуживать это — это совсем одно.
Совсем другое, когда ты начинаешь решать задачу, у которой сейчас просто нет best practicie, или они, мягко говоря, не лучшие. В этом случае человек оказывается в совершенно другом состоянии — свободного поиска, творчества.
Разница в том, что для best practicie нужно просто знать основы и сами practicie, а для свободного поиска — готовность пробовать самые безумные варианты и искать то, чего не нашли коллеги.
Совсем другое, когда ты начинаешь решать задачу, у которой сейчас просто нет best practicie, или они, мягко говоря, не лучшие. В этом случае человек оказывается в совершенно другом состоянии — свободного поиска, творчества.
Разница в том, что для best practicie нужно просто знать основы и сами practicie, а для свободного поиска — готовность пробовать самые безумные варианты и искать то, чего не нашли коллеги.
Я не знаю, где ты видел администраторов, которые все делают только по «best practicie», это скорее какие-то внедренцы приходящие.
Нормальный админ почти всегда зянят решением задач для бизнеса и выбором методов решения, и многое делается именно по свободному поиску и собственному ощущению адекватности.
Нормальный админ почти всегда зянят решением задач для бизнеса и выбором методов решения, и многое делается именно по свободному поиску и собственному ощущению адекватности.
Я, например. Если можно использовать стандартную конфигурацию, я использую стандартную конфигурацию. Быстрее и проще.
Изобретать свои велосипеды при наличии альтернатив — глупо.
Изобретать свои велосипеды при наличии альтернатив — глупо.
Мы говорим не про стандартную конфигурацию (кстати моя паранойя не позволяет мне использовать сервер со «стандартной конфигурацией», как правило там слишком много разрешено), а про выбор (железа и софта) для решения какого-то круга задач с заданными условиями.
Для большинства задач уже давно существуют вполне элементарные и очевидные общие практики. Пять-десять запусков — и отлаженная конфигурация просто применяется «ещё раз».
вариантов решения одной и той же задачи, в рамках разных условия слишком много. особенно в опернсорсном варианте, хотя и под виндой то же немало. можно пять раз поднять джаббер на ejabberd, и неплохо знать его тонкости, а в следующий раз потребуется именно openfire с применением сложных схем синхронизаций с ldap, и нужно чуть ли не с нуля изучать (не сам протокол, а ньюансы администрирования, восстановления, тюнинг и т.п.).
Может. Но это не тот путь, про который я говорю.
Условно говоря, можно долго и тщательно вылизывать маленькую (большую, не важно — важно, что заведомо известную) инфраструктуру. Но есть и другой вариант — создавать такую инфраструктуру, которую до тебя никто не делал. Или если делал, то в злобных проприентарных кулуарах при полном отсутствии публичной информации об этом.
Условно говоря, можно долго и тщательно вылизывать маленькую (большую, не важно — важно, что заведомо известную) инфраструктуру. Но есть и другой вариант — создавать такую инфраструктуру, которую до тебя никто не делал. Или если делал, то в злобных проприентарных кулуарах при полном отсутствии публичной информации об этом.
Во первых ты говоришь про свой личный случай, и при этом имеешь ввиду какую-то очень узкую область, которую и выделить то в целую область нельзя.
Еще раз на пальцах — есть структура (сеть/железо/софт). На каждом месте эта структура создается по своему, со своими нюансами и имплементациями. Создается именно админом/архитектором. И это и будет работа админа. И там, при желании, будут точно так же такие же сторы, ксены, биллинги, что угодно, как и в твоем случае.
Объясняю — ты сейчас взял маленький кусоек работы админа, по созданию некого нового сервиса, раздул его до общемировых масштабов, потому что сам только этим и занят, и считаешь что это и есть та самая «профильная» работа. Это не так, это один из обычных кусочков реальной работы хорошего админа со сложной информационной системой. И не надо его ни выделять в отдельную группу «тру» админства, ни поклоняться. К тому же (имхо) в твоем случае ты еще немало залезаешь в программирование, а это уже совсем другая должность.
В общем тебя все время перекашивает на личном опыте, что по прошлой конторе, когда эникея называли админом по недоразумению, что на текущем, когда довольно узкую задачу (архитектор + программист + админ) называют админом.
В реальности админ сочетает в себе то, что я перечислял в посту, админство, архитектора и cio. А остальное — местечковые недоразумения.
Еще раз на пальцах — есть структура (сеть/железо/софт). На каждом месте эта структура создается по своему, со своими нюансами и имплементациями. Создается именно админом/архитектором. И это и будет работа админа. И там, при желании, будут точно так же такие же сторы, ксены, биллинги, что угодно, как и в твоем случае.
Объясняю — ты сейчас взял маленький кусоек работы админа, по созданию некого нового сервиса, раздул его до общемировых масштабов, потому что сам только этим и занят, и считаешь что это и есть та самая «профильная» работа. Это не так, это один из обычных кусочков реальной работы хорошего админа со сложной информационной системой. И не надо его ни выделять в отдельную группу «тру» админства, ни поклоняться. К тому же (имхо) в твоем случае ты еще немало залезаешь в программирование, а это уже совсем другая должность.
В общем тебя все время перекашивает на личном опыте, что по прошлой конторе, когда эникея называли админом по недоразумению, что на текущем, когда довольно узкую задачу (архитектор + программист + админ) называют админом.
В реальности админ сочетает в себе то, что я перечислял в посту, админство, архитектора и cio. А остальное — местечковые недоразумения.
Если компания и успешность бизнеса от it не зависит, то так и есть.
В обратном случае администратор определяет многие ньюансы работы фирмы, и его неадекватная работа может привести к большим потерям или краху бизнеса.
В обратном случае администратор определяет многие ньюансы работы фирмы, и его неадекватная работа может привести к большим потерям или краху бизнеса.
Отлично написано.
Пара добавлений:
— Хорошие отношения с бывшим работодателем позволяют с чистой совестью указывать его (работодателя) контакты в резюме в разделе «рекомендации», что повышает шансы у HR'ов.
— Одной из первых задач после сбора информации о сети я бы назвал создание резервных копий всего, что только можно и, главное, продумывание и тренировку восстановления из этих резервных копий. Как ни странно, об этом часто забывают и в случае ахтунга бегают кругами вокруг серверов, с бэкапами в руках и причитаниями «ой, бля, а где у нас есть загрузочный cd, а как нам завести сеть» и так далее и тому подобное. Не пренебрегайте этим!
Пара добавлений:
— Хорошие отношения с бывшим работодателем позволяют с чистой совестью указывать его (работодателя) контакты в резюме в разделе «рекомендации», что повышает шансы у HR'ов.
— Одной из первых задач после сбора информации о сети я бы назвал создание резервных копий всего, что только можно и, главное, продумывание и тренировку восстановления из этих резервных копий. Как ни странно, об этом часто забывают и в случае ахтунга бегают кругами вокруг серверов, с бэкапами в руках и причитаниями «ой, бля, а где у нас есть загрузочный cd, а как нам завести сеть» и так далее и тому подобное. Не пренебрегайте этим!
Добавьте же в пост ссылки на предыдущие части наконец, и залинкуйте их все вместе!
Да, 1-ая и 2-ая части есть у меня в избранном… Но неудобно же, ей богу!
Да, 1-ая и 2-ая части есть у меня в избранном… Но неудобно же, ей богу!
М… Я думаю, в финальной части я сначала оглавление размещу. Делать постоянную перелинковку между статьями лениво.
> Самый же ужасный вариант ухода — сразу после отпуска.
Иногда именно этот вариант ухода самый разумный. Иначе мало того, что премии за два месяца не увидишь; так еще и на финальной беседе директор на тебя ушаты помоев выльет: «Вы предатель интересов коллектива, предатель интересов фирмы, ...! Когда будете проситься обратно, тебя из принципа сюда больше не возьмем».
Иногда именно этот вариант ухода самый разумный. Иначе мало того, что премии за два месяца не увидишь; так еще и на финальной беседе директор на тебя ушаты помоев выльет: «Вы предатель интересов коллектива, предатель интересов фирмы, ...! Когда будете проситься обратно, тебя из принципа сюда больше не возьмем».
То есть вы гендиректору не верите, считаете, что эта сволочь так и хочет вас нае… ть. И зачем вы с таким работаете?
Оставлять их совести и быть выше. Если кругом, извиняюсь, мудаки, — это не повод и не оправдание для того, чтобы самому быть таким.
Ушел именно после отпуска. И все нормально. 2 недели отработал, замену себе нашел, документацию всю передал, первые дни активно помогал человеку. Так что все зависит именно от человека и его отношения, а не от времени ухода.
Не много оффтоп но все же, работаю значит в компании, кхм, эникейщиком, админом себя еще язык не поднимается, да и после статьи уж тем более :) Так вот, соблазнился шеф на CRM, большую, дорогую, многофункциональную, но черт возьми, чтоб всем было удобно, ее нужно допиливать, долго и тщательно, очень часто просто нет информации по возникшему вопросу, вобщем полный аврал, скажите соит ли продвигать мыслю что проще/дешевле/быстрее написать простенькую систему с нужными функциями (компания 25 человек), потому что сейчас эта црмка используется как справочник по клиентской базе, продолжать пилить или же продвигать новую систему? :)
«Дешевле написать» не будет.
Если оно действительно используется только как справочник клиентов, то вам будет достаточно локальной вики и/или электронной таблицы. Если же их недостаточно, то, возможно, ваш шеф и прав.
Кроме прочего, не факт, что лично вам известны все причины покупки. Возможно, планируется расширение компании, или какие-то шаги по расширению клиентской базы, под которые и делается внедрение. И которые с вами, как с технарем, никто не говорил, поскольку это не ваша компетенция.
Хотя может быть и так, что шефа банально нагрузили на покупку где-то за шашлычком с коньячком и теперь он и сам не рад, да отступать уже как бы поздновато.
В любом случае, как мне кажется, для вас лучше будет продолжать пилить существующее решение. Во-первых, вы не будете критиковать (пусть и непрямо) дирекцию за недальновидное решение. А во-вторых, как раз тот вариант, о котором писал автор — уже есть готовое сложное решение, в котором можно поковыряться за счет работодателя. Приобретете +много к опыту внедрения сложных систем.
Кроме прочего, не факт, что лично вам известны все причины покупки. Возможно, планируется расширение компании, или какие-то шаги по расширению клиентской базы, под которые и делается внедрение. И которые с вами, как с технарем, никто не говорил, поскольку это не ваша компетенция.
Хотя может быть и так, что шефа банально нагрузили на покупку где-то за шашлычком с коньячком и теперь он и сам не рад, да отступать уже как бы поздновато.
В любом случае, как мне кажется, для вас лучше будет продолжать пилить существующее решение. Во-первых, вы не будете критиковать (пусть и непрямо) дирекцию за недальновидное решение. А во-вторых, как раз тот вариант, о котором писал автор — уже есть готовое сложное решение, в котором можно поковыряться за счет работодателя. Приобретете +много к опыту внедрения сложных систем.
Про сертификаты вы все-таки неправы, я считаю. Скажем, трек от Cisco дает огромное количество как знаний, так и навыков именно работы с технологиями.
> а как программы выбирают, какой IP использовать в качестве source?
Чертов ctrl-enter…
Хотел написать, что программы не выбирают source ip address :-) Эта функция протокола IP, а его функциональностьреализовуется операционной систетой, а не приложениями.
Кстати, тот-таки курс Cisco CCNA все это очень хорошо и наглядно объясняет. А с CCNP даже операторские сети перестают казаться чем-то страшным и непонятным :-)
Хотел написать, что программы не выбирают source ip address :-) Эта функция протокола IP, а его функциональностьреализовуется операционной систетой, а не приложениями.
Кстати, тот-таки курс Cisco CCNA все это очень хорошо и наглядно объясняет. А с CCNP даже операторские сети перестают казаться чем-то страшным и непонятным :-)
Вообще-то, все уважающие себя серверные программы при исходящих соединениях позволяют указать, какой IP использовать в качестве SRC.
И что такое «функция IP-протокола» я не понимаю. Не хочу говорить «выкиньте пособия циски в мусорник», но прочитать того же Филимонова очень советую.
И что такое «функция IP-протокола» я не понимаю. Не хочу говорить «выкиньте пособия циски в мусорник», но прочитать того же Филимонова очень советую.
Да-да, и дальше эти программы при помощи API заставляют систему использовать для отправки пакетов тот или иной и source IP. Вы понимаете разницу между «присваивать source address» и «заставлять систему присваивать source address»? Или системным администраторам знать архитектуру приложений уже не обязательно? :-)
> И что такое «функция IP-протокола» я не понимаю.
То есть, фразs типа «межсетевая ардесация», «предотвращение бесконечной передачи информации в петлях» и «фрагментация сегментов» вы никак не связываете с IP?
И — спасибо, я очень хорошо себя чувствую с пособиями от Циско :-)
> И что такое «функция IP-протокола» я не понимаю.
То есть, фразs типа «межсетевая ардесация», «предотвращение бесконечной передачи информации в петлях» и «фрагментация сегментов» вы никак не связываете с IP?
И — спасибо, я очень хорошо себя чувствую с пособиями от Циско :-)
Начнём с начала.
IP-протокол — это протокол. Спецификация. Бумажка. Пачка IEEE, RFC и т.д. У них нет «функций», есть только описание взаимодействия.
Есть API различных ОС для взаимодействия с другими участниками сети с помощью протокола IP. Функции появляются уже тут, и они вовсе не являются «функциями IP-протокола», это «функции ОС для работы с IP».
Понятие «межсетевая адресация» (я не уверен, как она называется, но речь про отсылку фрейма на мак шлюза) во-первых описано в спецификациях IP, а во-вторых, реализовано в коде ОС (драйвера/модуля ядра ОС).
Функции же «предотвращения передачи информации в петлях» ни одна ОС не предоставляет. Стандарт требует убивать пакет с нулевым TTL и сообщать об этом, а так же уменьшать TTL при передаче, не более.
Я как раз про эту проблему с пособиями цисок и говорю — у них есть одна точка зрения на окружающий мир, и эта точка зрения идеально совпадает с функционалом их железа.
IP-протокол — это протокол. Спецификация. Бумажка. Пачка IEEE, RFC и т.д. У них нет «функций», есть только описание взаимодействия.
Есть API различных ОС для взаимодействия с другими участниками сети с помощью протокола IP. Функции появляются уже тут, и они вовсе не являются «функциями IP-протокола», это «функции ОС для работы с IP».
Понятие «межсетевая адресация» (я не уверен, как она называется, но речь про отсылку фрейма на мак шлюза) во-первых описано в спецификациях IP, а во-вторых, реализовано в коде ОС (драйвера/модуля ядра ОС).
Функции же «предотвращения передачи информации в петлях» ни одна ОС не предоставляет. Стандарт требует убивать пакет с нулевым TTL и сообщать об этом, а так же уменьшать TTL при передаче, не более.
Я как раз про эту проблему с пособиями цисок и говорю — у них есть одна точка зрения на окружающий мир, и эта точка зрения идеально совпадает с функционалом их железа.
Не соглашусь. Суть спецификаций протоколов как раз в том, чтобы абстрагироваться от конкретных устройств и описать правила взаимодействия «черных ящиков». Для протокола не имеет значение, кто, как и почему реализует правила обмена информацией, главное то, что эти правила соблюдены. И при проектировании протокола как раз учитывается, в каких целях он будет использоваться и какие возможности предоставлять. Это и есть функции протокола.
А уже реализует их кто как хочет. В этом плюс. Скажем, по VLAN вообще нет стандартов, каждый вендор строит их модель так, как хочет, главное, чтобы транки соответствовали стандарту 802.1Q, который уже — протокол.
Проблемы с пособиями циско нет как раз из-за этого: они дают понимание технологий без привязки к функциональности конкретного утройства. Понимая, как работает OSPF, настроить его что на Циско, что на Джунипер, что на Zebra можно при помощь гайдов по командам. Умея настроить OSPF на Zebra, но не понимая технологии и протокола, человек не может настроить его ни на чем другом, даже имея такой гайд.
А уже реализует их кто как хочет. В этом плюс. Скажем, по VLAN вообще нет стандартов, каждый вендор строит их модель так, как хочет, главное, чтобы транки соответствовали стандарту 802.1Q, который уже — протокол.
Проблемы с пособиями циско нет как раз из-за этого: они дают понимание технологий без привязки к функциональности конкретного утройства. Понимая, как работает OSPF, настроить его что на Циско, что на Джунипер, что на Zebra можно при помощь гайдов по командам. Умея настроить OSPF на Zebra, но не понимая технологии и протокола, человек не может настроить его ни на чем другом, даже имея такой гайд.
С первым утверждением я соглашусь, однако, в этой спецификации нет ответа на вопрос, какой интерфейс следует использовать для исходящего трафика от приложений. Разве нет?
А то касается цисковых «non-vendor specific manuals» — расскажите мне про NAT «без привязки к циске» по цисковым мануалам. inside/outside — это общепринятая терминология?
Я тоже некоторое время думал, что то, как думают циски — это «вообще». На самом деле, нет — то, как они думают — это то, как хорошо сделано в цисках.
А то касается цисковых «non-vendor specific manuals» — расскажите мне про NAT «без привязки к циске» по цисковым мануалам. inside/outside — это общепринятая терминология?
Я тоже некоторое время думал, что то, как думают циски — это «вообще». На самом деле, нет — то, как они думают — это то, как хорошо сделано в цисках.
Не следует, конечно. То, что функции IP реализуются ОС значит, что именно она формирует пакет, и именно она решает, что класть в source address этого протокола.
По поводу NAT — inside/outside это ж чисто цисковские команды, они и не подаются как часть технологии.
Ну, помимо циски, я сейчас, вот, Джунипер ковыряю. В первый раз без никакой подготовки и будучи совершенно незнакомым с командами прошел их пробный тест JNCIA на 58%. Чисто на логике и знании технологий. Это заслуга цисковских мануалов (кстати, мы ж и про книги от CiscoPress сейчас говорим, да?) и знакомство с CCNA/CCNP курсами. Так что, думаю, вы как-то неправильно их воспринимаете :-)
По поводу NAT — inside/outside это ж чисто цисковские команды, они и не подаются как часть технологии.
Ну, помимо циски, я сейчас, вот, Джунипер ковыряю. В первый раз без никакой подготовки и будучи совершенно незнакомым с командами прошел их пробный тест JNCIA на 58%. Чисто на логике и знании технологий. Это заслуга цисковских мануалов (кстати, мы ж и про книги от CiscoPress сейчас говорим, да?) и знакомство с CCNA/CCNP курсами. Так что, думаю, вы как-то неправильно их воспринимаете :-)
Эникей, Админ, а что дальше?
Я уже стал старшим админом, хочу дальше…
Я уже стал старшим админом, хочу дальше…
А дальше я всех путей не знаю, но можете пойти по моему пути — проектировать свои системы.
Системный/сетевой инженер?
а дальше от жизненных интересов все зависит.
можно в CIO податься, можно к крупному интегратору и работать скажем с сетями уровня страны или с системами хранения уровня «круче не бывает»…
можно в CIO податься, можно к крупному интегратору и работать скажем с сетями уровня страны или с системами хранения уровня «круче не бывает»…
А цикл статей «Как перестать быть админом» будет?
Спасибо, полезный цикл. Прочел по диагонали, правда. А если эникеем уже лет 8? Клиника? Хотя где граница между эникеем и админом? Чтобы совсем не протухнуть изучаю новые для себя технологии, решения. Кручу верчу виртуальные сетки, гоняю по ним трафик. По поводу ситуации в Украине, в Донецке в частности — все же чаще встречаются работодатели типа «Денег мало, а работать должно все, как часы». По крайней мере так на текущих моих двух работах. и вспоминают о тебе, когда что-то ломается. Из всей этой ситуации, применительно конечно к своему региону, делаю вывод — нужно либо воткнуться в серьезную фирмы админом, либо прекращать этот опыт эникейства и уходить в программеры.
Тем более на работе наблюдаю парадоксальные ситуации, хотя привык уже если честно, аля
— Принтер/сервер заправить/починить нужно?
— Шо опять?! Да сколько же можно, где я денег столько возьму
Вот от этого и грустно, что у шефа необходимо выпрашивать деньги на приобретение/поддержание техники с помощью которой он эти же деньги и зарабатывает.
Но надеюсь и на нашей улице перевернется грузовик с перфокартами :)
Тем более на работе наблюдаю парадоксальные ситуации, хотя привык уже если честно, аля
— Принтер/сервер заправить/починить нужно?
— Шо опять?! Да сколько же можно, где я денег столько возьму
Вот от этого и грустно, что у шефа необходимо выпрашивать деньги на приобретение/поддержание техники с помощью которой он эти же деньги и зарабатывает.
Но надеюсь и на нашей улице перевернется грузовик с перфокартами :)
Граница — в ответственности. Эникей, который планирует топологию сети, уже делает работу админа, дальше вопрос только в названии должности.
Проблема состоит только в том, что руководитель (хозяин) эту границу ответственности в упор не замечает, думая, что нормальное состояние всей инфраструктуры — работает, админ в этой ситуации — бездельник. А когда что-то не работает — админ опять же бездельник, не уследил, допустил и т.д.
Получаем классическую змею, кусающую себя за хвост.
Получаем классическую змею, кусающую себя за хвост.
UPD: опечатался
Ниже правильная форма диалога
— Принтер/сервер заправить/починить нужно!
— Шо опять?! Да сколько же можно, где я денег столько возьму?!
Ниже правильная форма диалога
— Принтер/сервер заправить/починить нужно!
— Шо опять?! Да сколько же можно, где я денег столько возьму?!
не хватает «быстрых» ссылок на предыдущие статьи. найти, конечно, не проблема, но удобнее, когда все статьи цикла ссылаются друг на друга
Решил добавить комментарий, не вспомнил пароль, не вспомнил почту, попробовал зарегистрироваться, пришлось оформлять коммент как отдельный топик.. Потом почту к счастью вспомнил старую. Весь топ сюда переносить не буду, только начало:
Эникейщик — системный администратор по обстоятельствам
Собирался просто добавить ответ на третью часть серии статей Как стать системным администратором — пособие для начинающих, но из — за утери старого акка от Хабра и новых правил регистрации пришлось оформлять как отдельный топик.
Прочел все три статьи серии вместе с комментариями и немного не согласен с несколько презрительным отношением к эникейщикам универсалам.
В связи с чем хочу рассказать свою историю (одна из стран СНГ):
Читать дальше →
Эникейщик — системный администратор по обстоятельствам
Собирался просто добавить ответ на третью часть серии статей Как стать системным администратором — пособие для начинающих, но из — за утери старого акка от Хабра и новых правил регистрации пришлось оформлять как отдельный топик.
Прочел все три статьи серии вместе с комментариями и немного не согласен с несколько презрительным отношением к эникейщикам универсалам.
В связи с чем хочу рассказать свою историю (одна из стран СНГ):
Читать дальше →
Sign up to leave a comment.
Как стать системным администратором — пособие для начинающих (часть 3)