Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 233
Системное администрирование потихоньку теряет свою актуальность
То-то хороших специалистов так не хватает, и мы регулярно не можем закрыть вакансию.
Хороших специалистов ни в одной сфере нет избытка.
Хотя бы с адекватными скиллам запросами и желанием учиться — вот кого реально не хватает, ИМХО.
Но тут и ситуация с рынком влияет — часто потенциальные работодатели хотят, чтобы был и швец, и жнец, и на дуде игрец за 30 тысяч где-нибудь в Москве или Питере. Столько этих «работать в нашем банке — большая честь» видел, аж жуть.
Хотя бы с адекватными скиллам запросами и желанием учиться — вот кого реально не хватает, ИМХО.
Но тут и ситуация с рынком влияет — часто потенциальные работодатели хотят, чтобы был и швец, и жнец, и на дуде игрец за 30 тысяч где-нибудь в Москве или Питере. Столько этих «работать в нашем банке — большая честь» видел, аж жуть.
Кроме 30 в Москве, бывает еще 15 в Ростове. Волшебная вакансия от крупнейшей (*) по обороту, веб-студии в Ростове.
Все знают, что такое Вебстрой, Орбитсофт и иже с ними, поэтому не надо показывать пальцем на юродивых. В Ростове сейчас грамотный спец найдет работу на 30-50, хотя он же с легкостью переедет в Москву или на фрилансе подымет в три раза больше.
А еще я так смотрю они очень «правильно» составили резюме:
Разрабатывать удобный‚ с точки зрения навигации‚ интерфейс web-сервера
Разрабатывать концепцию развития web-сервера.
Полностью с вами согласен. В моем городе(Челябинске) для меня потолок зарплаты как молодого сисадмина 30 тысяч. Работу даже на 25 тысяч с адекватными запросами работодателя найти сложно. Например: вакансия. За 25 тысяч требуется в одном лице с опытом от 3 лет и высшим образованием: сисадмин, начинающий программист 1С, web-программист, .NET программист.
Специализируйтесь, указанная вами вилка — это middle system administrator. Сеньор 100К-130К, архитектор от 120К, со знанием SAP, Oracle DB, HP-UX, Solaris на хорошем уровне — 150К и выше.
к которым автоматом добавляется необходимость постоянно быть на телефоне и звонки посреди ночи.
Частота подобных звонков — показатель качества вашей работы.
Но я работал в 3х достаточно крупных и известных в России хостинг компаниях.
Вы работали в «центральном» офисе, или в «региональном»? Обычно принято все «мозги» собирать в центре, а в регионах держать «руки». Разница в окладе соответствующая.
например реальность чисел в ЗП на hh
Скорее занижены. Как я уже писал ниже, на интересные позиции редко вилку увидишь.
Но есть ряд моментов. Например — если вы переезжаете в дефолт-сити, то вам надо будет снимать квартиру. 30-40к в месяц за однушку, которая не будет клоповником.
Сдалась вам Нерезиновая, живите где нравится, лишь бы интернет стабильный был. Если работали в хостинге, то откуда там ночные звонки, там смены, во всяком случае в хостингах, с которыми сталкивался лично. Опять же, если первая, вторая линия, то тупой работы валом, опыта мало и вечно задолбанный ну и 50-60К для второй линии хорошая зп. Сейчас так получилось, что фрилансю удаленно в одном хостинге, помогаю строить другой, так что внутреннюю кухню немного знаю. По поводу 25-30К есть хороший
З.Ы. Тема смотрю разрослась и много противоречий, что многие под «Системный администратор» понимают абсолютно разные профессии. Помогать бабушкам втыкать мышки, отвечать на телефонные звонки пользователей, заправлять принтеры и т.п. — это эникей, не системный администратор, отсюда и зп «ниже чем у программистов». Системный администратор, чаще всего человек знающий несколько языков программирования, скрипты, маршрутизацию, телефонию, базы данных, десяток разных ОС на среднем уровне (может поднять, настроить, понимает как работает, но без глубин) + специализируется глубоко на одной, максимум 2х темах в которых разбирается досконально. Для примера хостинг, человек может поставить nix+apache+nginx+sql настроить кое-какой тюнинг, возможно даже сделать лоадбалансер, фаирвол и простой антиддос — это средний уровень, если он же может отдебажить ядро, коммитит в используемые инструменты, знает какая настройка с каким железом лучше сочетается и какой прирост на статике даст кашкадирование на определенном контроллере, то это уже глубокий уровень, можно углублять бесконечно, тут предела нет и чем меньше людей знают нужную глубину, тем больше ЗП. Принцип простой, знаешь как все — получаешь как все.
анекдот:
— Что должен делать системный администратор за зарплату в 30000р.
— Ничего и даже немного вредить.
— Ничего и даже немного вредить.
З.Ы. Тема смотрю разрослась и много противоречий, что многие под «Системный администратор» понимают абсолютно разные профессии. Помогать бабушкам втыкать мышки, отвечать на телефонные звонки пользователей, заправлять принтеры и т.п. — это эникей, не системный администратор, отсюда и зп «ниже чем у программистов». Системный администратор, чаще всего человек знающий несколько языков программирования, скрипты, маршрутизацию, телефонию, базы данных, десяток разных ОС на среднем уровне (может поднять, настроить, понимает как работает, но без глубин) + специализируется глубоко на одной, максимум 2х темах в которых разбирается досконально. Для примера хостинг, человек может поставить nix+apache+nginx+sql настроить кое-какой тюнинг, возможно даже сделать лоадбалансер, фаирвол и простой антиддос — это средний уровень, если он же может отдебажить ядро, коммитит в используемые инструменты, знает какая настройка с каким железом лучше сочетается и какой прирост на статике даст кашкадирование на определенном контроллере, то это уже глубокий уровень, можно углублять бесконечно, тут предела нет и чем меньше людей знают нужную глубину, тем больше ЗП. Принцип простой, знаешь как все — получаешь как все.
если кто то знает хоть один язык программирования ради чего заворачиваться чем то ещё
Знание русского языка делает вас поэтом? Нет? Тогда почему знание языка программирования должно сделать человека программистом?
не легче ли работать разработчиком на этом языке?
Вам главное, чтобы полегче, или чтобы поинтереснее да вдобавок и поприбыльнее? Самая легкая (хотя это еще как посмотреть) работа у охранников — весь день сидишь и ничего не делаешь. Кстати, у них вроде бы зарплаты выше, чем названные вами 25-30к. Не хотите пойти в ЧОП?
Т.е. если это действительно язык программирования и его действительно знают, а не однострочники на баше пишут.
На баше и многострочники, и многоэкранники можно писать, с весьма серьезной логикой, в нем есть своя прелесть. Кстати, это довольно сложный язык. Один и тот же цикл может выполняться как долю секунды (если уметь), так и минуту (если не уметь). Вот например кусок моего кода (надеюсь, излишне говорить, что я считаю себя не программистом, а унылым говнокодером?):
Скрытый текст
for i in $CODES
do
j="${i%%\!*}"
j=$((j-1))
echo "${TRUNK[$j]},$i" >> temp.txt
doneОно отрабатывает мгновенно на десятках тысяч элементов. А нечто содержащее «cut» вместо первой операции может тупить ту самую минуту, что критично для скрипта, который должен запускаться каждую минуту. Вот вы как администратор *NIX сможете разъяснить, что вообще делает та первая строчка? А то вон аж называете bash не языком программирования…
> Не хотите пойти в ЧОП?
К слову, ЧОП и охрана бывают очень разными. Неплохие деньги требуют неплохой бэкграунд, подготовку, знания и поддержание себя в форме. Ну и я уже не говорю про проф. риск.
К слову, ЧОП и охрана бывают очень разными. Неплохие деньги требуют неплохой бэкграунд, подготовку, знания и поддержание себя в форме. Ну и я уже не говорю про проф. риск.
Ну допустим если вы зайдете в отделение любого банка и посмотрите на любого охранника — ему не нужен бэкграунд, подготовка, знания и форма (ну разве что ему желательно выглядеть хоть немного внушительно). Риска тоже нет. Прав — практически нет, он может разве что вежливо (ни в коем случае не применяя силу) попросить хулигана выйти или блондинку запарковаться по-человечески. Если нападут — он мирно ляжет мордой в пол, желательно успев подать своим сигнал, и вот после этого через какое-то время на сцене появятся действительно подготовленные ребята. Но подготовленных, конечно, меньшинство, и вы их не видите.
А то, что показывают в кино про ограбления, имеет слабое отношение к реальности.
А то, что показывают в кино про ограбления, имеет слабое отношение к реальности.
Я не особо знаю, что показывают в кино про ограбления, т.к. не фанат подобных фильмов. Но я немного знаю людей, которые работают в приличных ЧОП. Да, там есть разные люди, но те, кто реально зарабатывают на этом — имеют и соотв. скиллы.
но те, кто реально зарабатывают на этом — имеют и соотв. скиллы.
Грубо говоря — есть ЧОПовцы-охранники, и есть ЧОПовцы-бойцы.
Первые (про которых я и говорю, и которых подавляющее большинство) запросто способны получать больше названных выше 20-30к (я знаю одного такого товарища, который ушел в ЧОП из какого-то НИИ, где он в машинных кодах писал софт для наших ракет, потому что денег платят в несколько раз больше — и этот товарищ втихаря под тумбочкой почитывал учебник по С++, чтобы, как он говорит, вконец не отупеть).
Вторые могут получать как неплохой программист и выше, но тут уже есть и требования к подготовке, и сильно отличный от нуля риск получить несовместимое с жизнью отравление свинцом…
Если я правильно распарсил 3 строку то код делает следующее:
for i in $CODES #Создаем цикл, выполняемый поочередно с каждым значением из переменной $CODES, где номер значения по порядку равен переменной i
do # Начало цикла
j="${i%%\!*}" #В переменную j кладем подстановку значения i с удаленными всех подстрок !и любой символ
j=$((j-1)) # Уменьшаем значение j на 1
echo "${TRUNK[$j]},$i" >> temp.txt #Выводим строку типа Значение переменной TRUNK[значение j], значение i и добавляем в конец файла temp.txt
done #Конец цикла
Скрытый текст
$ i='123!456'
$ j="${i%%\!*}"
$ echo $j
123
Простой для понимания аналог:
j=$(echo $i | cut -f1 -d'!')
Т.е. всего-то записать в j то, что перед первым восклицательным знаком в строке.
Вот только запуск cut (как и любой внешней программы, будь то sed, egrep и так далее) в цикле стоит чертовски дорого...
$ j="${i%%\!*}"
$ echo $j
123
Простой для понимания аналог:
j=$(echo $i | cut -f1 -d'!')
Т.е. всего-то записать в j то, что перед первым восклицательным знаком в строке.
Вот только запуск cut (как и любой внешней программы, будь то sed, egrep и так далее) в цикле стоит чертовски дорого...
Хм, я думал аналог будет так
$ j="${i%%\!.*}" а в вашем случае только 1 символ, ошибся,
проверил, вы правы точка не нужна, но если вхождение подстроки всего одно, зачем использовать %%, достаточно %, но это уже нюансы.
$ j="${i%%\!.*}" а в вашем случае только 1 символ, ошибся,
проверил, вы правы точка не нужна, но если вхождение подстроки всего одно, зачем использовать %%, достаточно %, но это уже нюансы.
Даже если захочу не возьмут
Вы серьезно?
www.alternativa-m.ru/index.php/4
Требования: Российское гражданство, физически крепкий, пунктуальный, без вредных привычек, аккуратный. Наличие удостоверения частного охранника. Опыт работы в торговом центре приветствуется.
Никакой службы в армии, тем более никакого КМС. Получить удостоверение не сложнее, чем любой другой документ, это ведь не разрешение на огнестрел. А отсутствие роста могла бы заменить ширина или просто угрожающий взгляд :)
Умение понимать программы, находить ошибки и править по месту по необходимости, и умение писать программы — две разные задачи (вторая обычно включает первую).
На уровень младшего программиста такого админа, конечно, с руками оторвут, но зачем ему это, да еще и с понижением зарплаты скорее всего?
На уровень младшего программиста такого админа, конечно, с руками оторвут, но зачем ему это, да еще и с понижением зарплаты скорее всего?
Одно дело программировать для себя в удобное время и оптимизировать свою работу, другое писать на заказ. Все админы, которых я знаю лично, знают несколько ЯП + несколько скриптовых языков, без этого в администрировании нельзя, вернее можно, но очень грустно. Вот понадобилось вам срочно сделать парсер лога, который отфильтрует события определенного типа, сделает выборку, проанализирует ее и на основании результата предпримет какие-либо действия — это задача в администрировании очень частая, но как ее решить без знания хотя-бы шела я не знаю. Или например при определенных условиях ядро валится в панику, коредамп примерно указывает причину, зная программирование заходим, меняем значение в месте падения под себя, пересобираем и радуемся, не зная этого опять же что делать? (Вот только на прошлой неделе пересобирал фрю и правил исходники, т.к. какой-то хороший человек догадался захардкодить количество семафоров в разделяемой памяти и именно в моем окружении их не хватило, после 6 часов в отладке нашел и проблему устранил раз и на долго). Да и работа разработчикам не всем нравится.
Тонкость в том что у разработчиков ЗП раза в 3 выше чем у админов.
Ась?
Например названная мною сумма для разработчика с опытом не такая большая
Ощутимая. Для senior — маловато, а вот для середнячка — вполне нормально.
devops же, ну. лучшее от двух миров (администрирования и программирования).
Синтаксис Perl может не очень отличаться от C, зависит от вас.
Для поддержки облачных технологий, тоже нужны админы
Системное администрирование потихоньку теряет свою актуальность и в недалеком будущем, вероятно, эта профессия изменится, станет горячим стартом и, возможно, стажировкой для все более новых программистов и других всенаправленных it-специалистов. Но не более.
Всегда считал, что хороший сисадмин это программист, а хороший программист это сисадмин. В смысле знания компьютера, его архитектуры, ОС и т.д.
Т.е. когда вы станете директором компании, вы не будете нанимать людей «С высшим образованием, опытом верстки, дизайна, программирования, администрирования 1C/SQL/DB2/Oracle, знанием bash/perl/python» и всё это за 25 тысяч?
Известные мне руководители подразделений шарахаются от таких резюме как от чумы.
1) Человек, который знает настолько разные области, не знает ничего.
2) Нам не нужен человек, который оценивает себя всего в 25 тысяч. Почему он просит раза в 3-4 ниже рынка? Где подвох?
1) Человек, который знает настолько разные области, не знает ничего.
2) Нам не нужен человек, который оценивает себя всего в 25 тысяч. Почему он просит раза в 3-4 ниже рынка? Где подвох?
Здесь имеются в виду именно такого рода вакансии, скорее всего. А их постят как раз по требованиям руководителя.
Так в мелких фирмочках — возможно. Но приличный работодатель никогда не наймет «мастера во всём, работающего за еду». С ним компания больше потеряет, чем приоритет. У всех HR'ов есть вилка зарплаты, а вилка подразумевает две границы — сверху и снизу. Лишь в исключительном случае работодатель взглянет на того, кто просит денег заметно ниже рынка.
Это не он просит, а вы предлагаете.
Когда я стал начальником отдела программирования и технического сопровождения, моими первыми вакансиями были:
Системный программист
Должностные обязанности:
1. Модернизация и тестирование программной платформы, являющейся собственной разработкой компании. Написание пользовательской и технической документации;
2. Создание web сайтов с использованием предложенной платформы;
3. Поддержка и сопровождение созданных web сайтов.
___________
Требования:
1. Углубленное знание языков программирования PHP версии >= 5.4 и JavaScript;
2. Знание основ языков разметки XML и HTML;
3. Углубленное знание языков запросов SQL (платформенные отличия);
4. Использование парадигмы ООП, знание основных шаблонов проектирования и тестирования;
5. Общие знания в области разработки ПО, знание UML;
6. Приветствуется знание библиотеки YUI 3.0 (http://yuilibrary.com);
7. Приветствуется владение системой git (http://git-scm.com);
8. Приветствуется опыт работы.
______________
Условия труда:
1. Модернизация и тестирование программной платформы, являющейся собственной разработкой компании. Написание пользовательской и технической документации;
2. Создание web сайтов с использованием предложенной платформы;
3. Поддержка и сопровождение созданных web сайтов.
___________
Требования:
1. Углубленное знание языков программирования PHP версии >= 5.4 и JavaScript;
2. Знание основ языков разметки XML и HTML;
3. Углубленное знание языков запросов SQL (платформенные отличия);
4. Использование парадигмы ООП, знание основных шаблонов проектирования и тестирования;
5. Общие знания в области разработки ПО, знание UML;
6. Приветствуется знание библиотеки YUI 3.0 (http://yuilibrary.com);
7. Приветствуется владение системой git (http://git-scm.com);
8. Приветствуется опыт работы.
______________
Условия труда:
$money = 8000; // 12000, 15000, 18000, 20000
for($day = 1; $day 9 && $hour < 18){
____if(work()){
______$money += 200; // 300, 400
____}
____else{
______eatCookies(2);
____}
____$hour++;
__}
}
_______________
Прочие условия:
createRecordOfService();
refresherCourse();
$candidate->add(new Experience());
$candidate->setWorkplace(new Chair(), new Table(), new Comp());
$candidate->eyeColor('red');
Разработчик GUI
Должностные обязанности:
1. Модернизация и тестирование слоя визуализации программной платформы, являющейся собственной разработкой компании. Написание пользовательской и технической документации;
2. Создание интерфейса web сайтов с использованием предложенной платформы;
3. Поддержка и сопровождение созданных web сайтов.
___________
Требования:
1. Углубленное знание языка программирования JavaScript;
2. Углубленное знание языков разметки XML и HTML;
3. Знание основ web дизайна, языка CSS, инструментов создания векторной и растровой графики;
4. Использование парадигмы ООП, знание основных шаблонов проектирования и тестирования;
5. Общие знания в области разработки ПО, знание UML;
6. Приветствуется знание библиотеки YUI 3.0 (http://yuilibrary.com);
7. Приветствуется владение системой git (http://git-scm.com);
8. Приветствуется опыт работы.
______________
Условия труда:
1. Модернизация и тестирование слоя визуализации программной платформы, являющейся собственной разработкой компании. Написание пользовательской и технической документации;
2. Создание интерфейса web сайтов с использованием предложенной платформы;
3. Поддержка и сопровождение созданных web сайтов.
___________
Требования:
1. Углубленное знание языка программирования JavaScript;
2. Углубленное знание языков разметки XML и HTML;
3. Знание основ web дизайна, языка CSS, инструментов создания векторной и растровой графики;
4. Использование парадигмы ООП, знание основных шаблонов проектирования и тестирования;
5. Общие знания в области разработки ПО, знание UML;
6. Приветствуется знание библиотеки YUI 3.0 (http://yuilibrary.com);
7. Приветствуется владение системой git (http://git-scm.com);
8. Приветствуется опыт работы.
______________
Условия труда:
var candidate = (function(){
__var money = 0;
__return {
____work: function(day, hour){
______if(day >= 1 && day 9 && hour < 18){
__________playWithFonts();
__________this.addMoney(200); // 300, 400
________}
________else{
__________alert('Noup!');
________}
______}
______else{
________alert('Наши сотрудники не работают сверх нормы!');
______}
____},
____addMoney: function(m){
______money += m;
____}
__}
})();
candidate.addMoney(8000); // 12000, 15000, 18000, 20000
while(1){
__candidate.work();
}
_______________
Прочие условия:
createRecordOfService();
refresherCourse();
candidate.add(new Experience());
candidate.setWorkplace(new Chair(), new Table(), new Comp());
candidate.eyeColor('red');
createRecordOfService();
refresherCourse();
$candidate->add(new Experience());
$candidate->setWorkplace(new Chair(), new Table(), new Comp());
$candidate->eyeColor('red');
У вас нэйминг методов… не очень. И путаете ооп с функциональщиной.
Собственно, ваш системный программист — это php кодер, которому зачем-то нужен uml.
Ну все люди разные, спорить о таком бесполезно, но:
Цель — «внедрить Х» к примеру. К этой цели можно идти и год-два, в зависимости от масштабов задачи и кучи других факторов.
Хреново налаженный процесс. Не должно быть срочных задач и вызовов. Должны быть заявки, на которые можно выделить, скажем, час времени.
Я например весь понедельник и половину вторника провел в написании одного bash скрипта. Как-то не было прерываний. Да и коллеги, опять же, есть.
И тут появляется нечто новое, восхитительное. В новой версии софта появилась интереснейшая фича. Вышла новая классная железяка, которую надо купить и внедрить. И так далее.
Вы это называете недостатком? По-моему, наоборот, ради такого и стоит жить.
У хороших системных администраторов проектов на год-два вперед расписано. И это я сейчас даже не про интеграторов говорю, а про штатных сотрудников.
Я такое замечаю в случае тех, кто изначально неправильно выбрали направление деятельности и у кого это не слишком хорошо получалось.
Знаю я одного матёрого связиста, которому лет 70 (седой такой дедок), работает в крупном банке, сейчас занимается оптическим транспортом в целом и DWDM в частности. Говорят, уже крутейший специалист в этом деле. До этого была IP телефония. До этого аналоговая телефония.
А подумайте: раз расширяются облака и аутсорсеры (хотя на самом деле это не совсем так, но допустим) — значит, им надо больше людей на сопровождение инфраструктуры? И даже если мелкие компании могут целиком перейти на аутсорс — в случае крупных это решительно невозможно, только малую часть задач можно передать на сторону.
сам процесс поддержки, а точнее его «постоянная» природа или отсутствие какой-либо завершенности.
Цель — «внедрить Х» к примеру. К этой цели можно идти и год-два, в зависимости от масштабов задачи и кучи других факторов.
Когда пишешь код, оптимизируешь сервис и каждые полчаса тебя отвлекают вопросами, срочными задачами и вызовами — вернуться в работу порой очень тяжело и на это тратится время
Хреново налаженный процесс. Не должно быть срочных задач и вызовов. Должны быть заявки, на которые можно выделить, скажем, час времени.
Я например весь понедельник и половину вторника провел в написании одного bash скрипта. Как-то не было прерываний. Да и коллеги, опять же, есть.
то, что изначально вызывало восхищение и приносило в итоге общее удовлетворение, — становится обыденным и скучным
И тут появляется нечто новое, восхитительное. В новой версии софта появилась интереснейшая фича. Вышла новая классная железяка, которую надо купить и внедрить. И так далее.
Трудовые будни с дикой нагрузкой. С институтских времен я так не напрягал свой мозг.
Вы это называете недостатком? По-моему, наоборот, ради такого и стоит жить.
У хороших системных администраторов свободного времени намного больше, чем они говорят.
У хороших системных администраторов проектов на год-два вперед расписано. И это я сейчас даже не про интеграторов говорю, а про штатных сотрудников.
в последнее время очень много знакомых админов начинает готовится к перепрофилированию или уже поменяли профессию.
Я такое замечаю в случае тех, кто изначально неправильно выбрали направление деятельности и у кого это не слишком хорошо получалось.
Знаю я одного матёрого связиста, которому лет 70 (седой такой дедок), работает в крупном банке, сейчас занимается оптическим транспортом в целом и DWDM в частности. Говорят, уже крутейший специалист в этом деле. До этого была IP телефония. До этого аналоговая телефония.
А развитие облачных технологий и расширение влияния аутсорсинговых компаний, только усиливают эту тенденцию.
А подумайте: раз расширяются облака и аутсорсеры (хотя на самом деле это не совсем так, но допустим) — значит, им надо больше людей на сопровождение инфраструктуры? И даже если мелкие компании могут целиком перейти на аутсорс — в случае крупных это решительно невозможно, только малую часть задач можно передать на сторону.
Хреново налаженный процесс. Не должно быть срочных задач и вызовов. Должны быть заявки, на которые можно выделить, скажем, час времени.
Я например весь понедельник и половину вторника провел в написании одного bash скрипта. Как-то не было прерываний. Да и коллеги, опять же, есть.
Угу, к сожалению, достаточно многие и не слышали про тот же ITIL, налаживание рабочего процесса… Лучше паника и срочный вызов героя, который всех спасет и все починит — это заметнее :)
Вы это называете недостатком? По-моему, наоборот, ради такого и стоит жить.
В точку, отсутствие вызовов (которые challenge) ведут к деградации и падению самооценки. К личностному и профессиональноиу развитию нахождение в «зоне комфорта» подталкивает слабо.
Угу, к сожалению, достаточно многие и не слышали про тот же ITIL, налаживание рабочего процесса… Лучше паника и срочный вызов героя, который всех спасет и все починит — это заметнее :)
Всегда были и есть компании, в которых человек занимается своим делом и те, в которых занимается всем сразу. У Вас же есть выбор? ITIL… да почти никто по нему не работает. Проходят для сертификации и все.
к сожалению, достаточно многие и не слышали про тот же ITIL
К счастью. Не к сожалению, а к счастью. То, что я описал, работало и до внедрения ITIL, потому что это эффективно и удобно. После внедрения ITIL изменений в лучшую сторону не было, в худшую — полно от не до конца переработанных бизнес-процессов (фактически — половина задач все равно выполнялась в обход ITIL, только по более длинной цепочке) до кучи возни с бумажками (пусть даже виртуальными).
На мой взгляд ITIL эффективен когда Вы не планируете частых сильных сдвигов в инфраструктуре: т.е. Вы определились с процессом, определились с технологиями и все что делаете — наращиваете мощности. Если Вы хотите оставаться гибким и строить динамичную компанию — ITIL это лишнее препятствие. ITIL, как и почти любой «оптимизированный» процесс или система процессов устроен против природы человека. Если речь об IT (именно админство, DevOps) идет как о ключевой части бизнеса (IT аутсорс, к примеру) — это идеальное решение для интерфейса с клиентом. Если же это IT отдел небольшой компании в 50 — 100 человек, в котором 10 админов и пара руководителей — то ИМХО это перебор. Работал в двух диаметрально-противоположных компаниях, и я убежден что сила в Agile, а не в процессах. Как сравниваю? По фактическим достижениям и прибыли :) Да, падает, да паника, но за это время в Agile проходит десять итераций, а в процессной модели одна. И оказывается что мы построили идеальный процесс, а он оказался не нужен. Почему? Потому что продукт который мы делали — дерьмо. Следующая интерация? Да, начнем с описания процесса и отслеживания каждого изменения! :) Я за Agile! Ну или хотя бы за микс, если это необходимо.
Вы это называете недостатком? По-моему, наоборот, ради такого и стоит жить.
В точку, отсутствие вызовов (которые challenge) ведут к деградации и падению самооценки. К личностному и профессиональному развитию нахождение в «зоне комфорта» подталкивает слабо.
challenge — это очень хорошо, но задача решается и остаётся ощущение, что тебя нае… :) То, что было вызовом, становится рутиной. Сам с этим столкнулся.
Параллельно с этим, есть семья и внезапно понимаешь, что ей ты уделяешь времени недопустимо мало. При том, что у меня старшему сыну 6 с половиной, я осознал это буквально недавно. Сейчас у меня новая задача: как не помереть от скуки, найти новый вызов так, чтоб у меня оставалось достаточно времени заниматься сыновьями.
Как там, в анекдоте: «у вас замечательные дети. Но то, что вы делаете руками, никуда не годится» :)
У того же Лимончелли написано как обеспечить себе дни без прерываний: меняйтесь с коллегами (сегодня я хожу на вызовы, завтра ты), обучайте пользователей и т.д.
Хреново налаженный процесс. Не должно быть срочных задач и вызовов. Должны быть заявки, на которые можно выделить, скажем, час времени.
Прибегает, бухгалтер: «У меня накладная из 1С не печатается, а люди ждут, время горит», звонит директор: «у меня письмо с многомиллионным контрактом не отправляется». И так постоянно.
В новой версии софта появилась интереснейшая фича. Вышла новая классная железяка, которую надо купить и внедрить.
Кто даст деньги на новый Catalyst за полляма, когда и 10-летний выполняет свои функции на 5+?
У хороших системных администраторов проектов на год-два вперед расписано.
Честно не верю, у хорошего сисадмина все должно быть автоматизировано до такой степени, чтоб 90% задач в пару кликов делалось. На своем примере, в первый месяц работы на текущем месте, у меня было 2 часа активной работы в день. Спустя 3 месяца все тоже делается за 8-10 минут.
в последнее время очень много знакомых админов начинает готовится к перепрофилированию или уже поменяли профессию.
Среднему сисадмину платят раза в 1,5-2 меньше, чем среднему программисту с тем же опытом. Почему бы и нет.
По поводу облаков: Железо облаков как правило стоит в ЦОДах, там количество железа на одного сисадмина в десятки раз больше, т.е. сисадминов требуется гораздо меньше. чем было до внедрения облака.
Прибегает, бухгалтер: «У меня накладная из 1С не печатается, а люди ждут, время горит», звонит директор: «у меня письмо с многомиллионным контрактом не отправляется». И так постоянно.
Ответ: «какого черта ты пришел ко мне? Заведи инцидент через сервисменеджер, пусть он пройдет по цепочке эскалации». Указанные вами проблемы решаются первой линией поддержки по инструкции, до администраторов такие вещи не должны доходить никогда.
Кто даст деньги на новый Catalyst за полляма, когда и 10-летний выполняет свои функции на 5+?
Старый 7200, терминирующий сотни DMVPN туннелей, прогружен до 70% по ЦП в среднем. Покупается блестящий ASR1k.
Старые каталисты 3750, верно служившие в ЦОДах, имеют один ввод питания и не имеют 10G аплинков, а 1G уже впритык, и серверам с корзинами неплохо бы 10G. Покупаются нексусы.
И так далее.
Среднему сисадмину платят раза в 1,5-2 меньше, чем среднему программисту с тем же опытом.
Конкретных цифр не назову, но это утверждение не соответствует действительности. Начнем с того, что в моем городе средний сисадмин получает тысяч 60-70 в месяц.
Да и вы за зарплату работаете, или за удовольствие от работы? Мое мнение — денег должно быть «достаточно». Если сейчас денег «достаточно», а на новом месте предлагаю в два раза больше, то финансовый вопрос рассматривается в последнюю очередь.
Железо облаков как правило стоит в ЦОДах, там количество железа на одного сисадмина в десятки раз больше
Сисадмину не важно количество железа, он его почти никогда и не видит.
1. Какой сервис менеджер, когда 1 сисадмин на 2 региона?
2. Старый справляется, нагрузка маленькая, кто даст деньги?
3.
25 тысяч(по городу потолок 30), для молодого человека без своего жилья, я считаю что это не «достаточно».
2. Старый справляется, нагрузка маленькая, кто даст деньги?
3.
Да и вы за зарплату работаете, или за удовольствие от работы?
25 тысяч(по городу потолок 30), для молодого человека без своего жилья, я считаю что это не «достаточно».
Какой сервис менеджер, когда 1 сисадмин на 2 региона?
Очевидно — надо стремиться туда, где полсотни человек на один регион.
Старый справляется, нагрузка маленькая, кто даст деньги?
Очевидно, что тогда новый и не нужен. У меня много подобного железа, которое и ssh сессий годами не видело. Работает и ладно. Хотя большинство этих железок запросто не переживет ребута, потому есть повод и задуматься о замене или хотя бы о ЗИПе.
25 тысяч(по городу потолок 30), для молодого человека без своего жилья, я считаю что это не «достаточно».
В таком случае, либо менять сферу деятельности, либо менять город. Что не надо делать, так это жаловаться — не говорите, что вы при выборе профессии не обладали этой информацией.
Кто даст деньги на новый Catalyst за полляма, когда и 10-летний выполняет свои функции на 5+
Обычно такие проблемы возникают в относительно мелких компаниях, если говорить про телеком, банк, крупные компании ( 1000 и больше человек), то там все немного по другому.
Не нужно просить денег только потому, что одна железка старая, а другая новая. Нужно приводить аргументы как новая железка/новый софт поможет улучшить бизнес компании.
Например:
1) 7200 уже снята в EOS, скоро на нее даже новый контракт нельзя будет купить, Если она упадет, что будет с компанией? насколько критична потеря связи с 50 офисами?
2) Процесс выкатки новых прошивок на устройства, занимает у сотрудниуков 2 дня ( пусть устройств будет 100). Если мы купим систему управления которая это может делать сама, то появятся ресурсы на X,Y,Z. И привести анализ, на сколько NMS разгрузит отдел.
3) Интернет канал перегружен, страдает телефония, кто перегрузил — не понятно. Внедряем систему мониторинга трафика ( Netflow или DPI)
Это условные кейсы, просто чтобы показать идею.
Автор статьи на 90% работал в относительно маленькой компании, где админ это 1С+windows+linux gateway+принтеры. Если сотрудник приходит к старшему админу с вопросом о принтере, это хороший показать размера компании.
Если работать админом, то это или большая компания где есть потребность в нескольких админах с разделением обязанностей или телеком.
PS: если кто из Cisco админов считает, что ему не хватает челенджей — то ищите вакансии в интеграторах :) Там челенджей, дедлайнов, факапов и прочего более чем достаточно :)
Среднему сисадмину платят раза в 1,5-2 меньше, чем среднему программисту с тем же опытом. Почему бы и нет.
У меня в отделе сисадмин получал ровно столько же, сколько senior programmer (но меньше архитектора и начальника отдела).
Подтверждаю, со всем компаниями где сотрудничал уровень примерно один, разве что джуниоры программисты получают больше джуниоров админов, на мидлах уже сравнивается, сеньоры в пределах погрешности +-100$, архитектор админ может получать даже больше архитектора программиста, если на предприятии суровый энтерпрайз и на сетевую инфраструктуру завязаны все бизнес процессы, развернуты продукты SAP, Oracle и т.п
Я такое замечаю в случае тех, кто изначально неправильно выбрали направление деятельности и у кого это не слишком хорошо получалось.
А теперь уберите «звёзд» из выражения и снова попробуйте оценить рынок.
Я их и не рассматриваю.
А если под «админами» понимаются те самые шивы, то я считаю это необходимым, но лишь переходным этапом. Либо к узкоспециализированному профессиональному администратору, у которого нет причин жаловаться на пользователей по причине почти полного отсутствия всяких контактов с ними, либо к чему-то совсем другому вроде того же программирования.
Когда-то давно я работал тем самым многоруким шивой, сначала один, потом вместе с одним пареньком. Тот паренек вообще-то учился на экономиста, наняли его что-то там делать с 1С, но как-то получилось, что он начал вместе со мной отвечать и за IT инфраструктуру фирмы (это было аж целых пять серверов и без всякой новомодной по тем временам виртуализации). Получалось это у него весьма неплохо. Из той конторы он уволился вскоре после меня, и, насколько я знаю, с тех пор его работа никакого отношения к IT не имела.
А если под «админами» понимаются те самые шивы, то я считаю это необходимым, но лишь переходным этапом. Либо к узкоспециализированному профессиональному администратору, у которого нет причин жаловаться на пользователей по причине почти полного отсутствия всяких контактов с ними, либо к чему-то совсем другому вроде того же программирования.
Когда-то давно я работал тем самым многоруким шивой, сначала один, потом вместе с одним пареньком. Тот паренек вообще-то учился на экономиста, наняли его что-то там делать с 1С, но как-то получилось, что он начал вместе со мной отвечать и за IT инфраструктуру фирмы (это было аж целых пять серверов и без всякой новомодной по тем временам виртуализации). Получалось это у него весьма неплохо. Из той конторы он уволился вскоре после меня, и, насколько я знаю, с тех пор его работа никакого отношения к IT не имела.
Речь про любых generic сисадминов, которых в лучшем случае ждёт перспектива дежурного подавана, благодаря облакам и консалтингу. У специалистов по экзотике ситуация немного лучше, но высок порог вхождения и небольшое количество вакансий.
Вообще, у меня сложилось впечатление, что из эксплуатационщиков не страдают только сетевеки — их облаками не заменить, да и вендоры не отнимают хлеб.
Вообще, у меня сложилось впечатление, что из эксплуатационщиков не страдают только сетевеки — их облаками не заменить, да и вендоры не отнимают хлеб.
Речь про любых generic сисадминов, которых в лучшем случае ждёт перспектива дежурного подавана
Так и это обычно один из начальных этапов развития.
У специалистов по экзотике ситуация немного лучше, но высок порог вхождения и небольшое количество вакансий.
Специалистов по экзотике сейчас катастрофическая нехватка на рынке. Есть ряд систем, по которым практически нереально закрыть вакансию. Несколько знающих эти системы людей сидят по интеграторам.
из эксплуатационщиков не страдают только сетевеки — их облаками не заменить
А винадминов? А юниксоидов? А прочих?
Средние и крупные компании принципиально не могут полностью (а нередко — даже частично) уйти в чужое облако.
Есть ряд систем, по которым практически нереально закрыть вакансию.
Так опасно рыпаться, когда на рынке полторы вакансии.
А винадминов? А юниксоидов? А прочих?
Винадминов кроет премьер-поддержка Microsoft, с VMware аналогично, про юниксоидов ничего не знаю.
Ещё ходят слухи, что IBM хочет натравить Watson для администрирования свохи продуктов.
Так опасно рыпаться, когда на рынке полторы вакансии.
Как правило, у относительно грамотного спеца эти полторы вакансии перманентно в кармане. Достаточно звонка, чтобы взяли.
Винадминов кроет премьер-поддержка Microsoft, с VMware аналогично
Это не замена, а дополнение. Невозможно обойтись саппортом вендора без хоть немного соображающих людей в штате.
Ещё ходят слухи, что IBM хочет натравить Watson для администрирования свохи продуктов.
Предыдущие известные мне попытки автоматизировать ряд задач (в первую очередь траблшутинг) позорно проваливались.
Невозможно обойтись саппортом вендора без хоть немного соображающих людей в штате.
Немного соображающим немного платят :-)
Делается это следующим образом: консалтинг пишет инструкцию на стандартные операции и оставляет телефон поддержки, которой надо звонить при возникновении ошибок или просто нестандартных задач. Там не набирают полных идиотов, но инициатива запрещена.
Предыдущие известные мне попытки автоматизировать ряд задач (в первую очередь траблшутинг) позорно проваливались.
Watson не совсем обычный и пока речь идёт о пусконаладке, которая у продуктов IBM занимает кучу времени.
Для меня одним из аргументов при оценке привлекательности профессии является перспектива переезда в цивилизованные страны и у программистов с этим намного проще.
Винадминов кроет премьер-поддержка Microsoft,
Нифига. У нас (точнее, у нашего заказчика) она есть, и ее не хватает (точнее, не устраивает скорость реагирования). Да и типовые работы им тоже не отдашь.
Более того, как раз первое, что они просят — контакт технического специалиста на стороне клиента.
Как же я вас понимаю…
Жизнь так сложилась, что работать(full-time) пришлось еще задолго до совершенолетия. Прошел путь от продавца до QA в телекоме и сейчас работаю сисадмином.
Крайне не хватает творческого начала в работе. До переезда в страну Москва справлялся с этим за счет театра и других ивентов.
Жизнь так сложилась, что работать(full-time) пришлось еще задолго до совершенолетия. Прошел путь от продавца до QA в телекоме и сейчас работаю сисадмином.
Крайне не хватает творческого начала в работе. До переезда в страну Москва справлялся с этим за счет театра и других ивентов.
Все познается в сравнении) Можно работать админом, заниматься интересными штуками (мне вот интересно, когда приходит какая-нибудь новая циска), параллельно калымить (сами же говорите — время остается), а на всякую мелочь типа эникея взять ребят молодых. А с подходом «все надоело» и программироване через несколько лет поменять захочется.
Все дело в том, что в системном администрировании недостаточно быть просто хорошим технарем, необходимо быть еще и немного управленцем. Необходимо не только уметь настраивать те или иные железки, но и понимать основные принципы управления качеством, анализа рисков, выстраивания процессов обслуживания и управления ИТ-инфраструктурой, уметь проводить переговоры с руководством, определять и достигать цели совместно с бизнесом (как бы булшитно это не звучало).
Отсутствие управленческих навыков, неспособность договорится о формате работы и ее целях, трудности определения причин дискомфорта в работе и конструктивных методов их устранения, зачастую приводит к тому, что хорошие технические специалисты остаются один на один с грудой неразрешенных управленческих проблем, которые постоянно на них давят. Данные проблемы, как правило, менее заметны в крупных ИТ-отделах и принимает катастрофические размеры в небольших организациях.
Именно это и побудило меня писать статьи на хабре, связанные с вопросами менеджмента в системном администрировании, и именно поэтому я стараюсь писать их максимально доступным языком, чтобы они были понятны даже для начинающих сисадминов.
Отсутствие управленческих навыков, неспособность договорится о формате работы и ее целях, трудности определения причин дискомфорта в работе и конструктивных методов их устранения, зачастую приводит к тому, что хорошие технические специалисты остаются один на один с грудой неразрешенных управленческих проблем, которые постоянно на них давят. Данные проблемы, как правило, менее заметны в крупных ИТ-отделах и принимает катастрофические размеры в небольших организациях.
Именно это и побудило меня писать статьи на хабре, связанные с вопросами менеджмента в системном администрировании, и именно поэтому я стараюсь писать их максимально доступным языком, чтобы они были понятны даже для начинающих сисадминов.
хорошие технические специалисты остаются один на один с грудой неразрешенных управленческих проблем, которые постоянно на них давят.
Ради такого есть товарищ по имени «начальник отдела», который является наполовину техническим специалистом, наполовину управленцем. Он должен снимать указанные задачи с рядовых бойцов. Еще есть всякие проектные менеджеры и так далее.
Я не хочу касаться вопросов менеджмента и десятиметровой палкой. И мне как правило удается их не касаться.
Должен вас разочаровать — есть компании, где кроме сисадмина нет больше ни одного технического специалиста в штате и это еще вопрос, где ИТ-специалистов работает больше — в мелких бизнесах или в составе крупных ИТ-отделов.
есть компании, где кроме сисадмина нет больше ни одного технического специалиста в штате
Такие компании следует рассматривать как первый, временный этап эволюции администратора.
Пример: маленькая контора, один сисадмин на 2 региона, все ИТ на мне, до этого никакого опыта административной работы. Вот у меня голова пухнет, от всего, начиная от заключения договоров до планирования бюджета. Зато новый опыт.
Многие с подобного начинали. У меня была похожая ситуация лет 10 назад, только в моем случае у меня и с техническими знаниями было туго (оглядываясь назад — тогда я не знал вообще ничего, и непонятно, как не развалил всё что было в первую же неделю). Денег платили меньше, чем я тратил на дорогу туда-обратно. Зато это был прекрасный опыт, я очень благодарен той компании.
Доля адекватных «начальников отдела» даже меньше, чем профессионалов среди сисадминов.
Ну мне админить наоборот в кайф, когда был программистом было в разы больше рутины и не интересных задач. Если админ — это эникей в описанной вами ситуации, когда каждой проблеме затычка, то да хочется уйти. Когда на тебе архитектура сети и ты видишь как осуществляется на глазах расписанный и посчитанный тобой проект, когда через твои руки проходят разные железяки стоимостью с частный самолет и ты изучаешь постоянно новые технологии, пытаешься применить передний край разработок на новых проектах — это кайф, который сложно передать. По вашему тексту:
Это функция отдела СТП, если вы «старший системный администратор» уровень senior, то, простите, какого овоща вы заняты рутиной? Что в это время делают остальные сотрудники IT департамента, а если вы в департаменте один и без подчиненных, то какой вы тогда старший?
Статус «я в отладке» на всех мессенджерах и отключенный звук, переадресация на заместителей, в белом списке только руководство предприятия и ключевые клиенты.
Так растите и задачи будут разные, не можете расти на одном предприятии, меняйте на другое. Надоели сети, перешли на сервера, надоели сервера — здравствуй телефония, снова надоело — привет защита информации, а вот и за сетями соскучились и что-то новое появилось.
То-есть это не вы ленивый, а работа виновата? С пользователями то зачем общаться старшему админу напрямую? Убирать кабинеты и за пиццой бегать вас хоть не заставляли?
Из вашего поста лично для меня вытекает вывод, что или вы работали в какой-то заднице, либо не смогли сами наладить рабочий процесс ну или просто это не ваша профессия.
Во-первых, сам процесс поддержки, а точнее его «постоянная» природа или отсутствие какой-либо завершенности. Мелкие задачи, выполняясь, накладываются друг на друга до бесконечности и превращаются в огромный ком, который постоянно меняет свои размеры, — соотношение выполненных и невыполненных задач. Что в итоге порождает вопросы: «Что полезного я уже сделал, Что еще сделаю и к Чему в итоге я двигаюсь?»
Это функция отдела СТП, если вы «старший системный администратор» уровень senior, то, простите, какого овоща вы заняты рутиной? Что в это время делают остальные сотрудники IT департамента, а если вы в департаменте один и без подчиненных, то какой вы тогда старший?
В-вторых, прерывания.
Статус «я в отладке» на всех мессенджерах и отключенный звук, переадресация на заместителей, в белом списке только руководство предприятия и ключевые клиенты.
В-третьих, привычка к рабочему процессу.
Так растите и задачи будут разные, не можете расти на одном предприятии, меняйте на другое. Надоели сети, перешли на сервера, надоели сервера — здравствуй телефония, снова надоело — привет защита информации, а вот и за сетями соскучились и что-то новое появилось.
Дело в самой профессии системного администратора. Работа, конечный итог которой стремится к абсолютной ле́ни, сильно расслабляет жизненные позиции и стремления, а общение с пользователями и выслушивание их недовольств, еще больше укрепляет асоциальные начала. И тут уже, кто как я, начинает задумываться о бо́льшей полезности, что приводит к поискам более гармоничной жизни, а кого все устраивает и он продолжает это нелегкое существование.
То-есть это не вы ленивый, а работа виновата? С пользователями то зачем общаться старшему админу напрямую? Убирать кабинеты и за пиццой бегать вас хоть не заставляли?
Из вашего поста лично для меня вытекает вывод, что или вы работали в какой-то заднице, либо не смогли сами наладить рабочий процесс ну или просто это не ваша профессия.
Да этот кайф передать сложно, когда все заканчиваешь, вводишь последние команды, и наблюдаешь как твой новый сервис оживает, растут нагрузки…
Это функция отдела СТП, если вы «старший системный администратор» уровень senior, то, простите, какого овоща вы заняты рутиной?
С пользователями то зачем общаться старшему админу напрямую?
Рутина как и пользователи (например руководители) бывают разными и в каждой организации они свои.
То-есть это не вы ленивый, а работа виновата?
А лень тут при том, что весь смысл администратора а автоматизации всего и вся, — работа сводится к приведению системы к виду, когда админы в принципе и не требуются.
работа сводится к приведению системы к виду, когда админы в принципе и не требуются.
Значит, вы не понимаете, зачем нужны администраторы. Нет, они нужны не для «чтобы все работало автоматически и не падало». Они нужны для максимального повышения эффективности работы технической части бизнес-процессов. Это подразумевает безграничный простор для совершенствования того, что уже есть.
А тот администратор, который вместо допиливания чего-то полезного сутками напролет играет в кваку («ничего не падает => могу заниматься чем угодно»), является не администратором, а аникеем.
После всех улучшений «технической части бизнес-процессов», дальнейший рост предполагает потребности компании, а если уже улучшать и допиливать нечего? Остается только поддержка, и такое бывает.
Если улучшать и допиливать нечего — остаётся или расслабиться и начать деградировать либо уволиться и искать новые challenge'ы. Каждый выбирает своё.
Если админу нечего улучшать, то он хреновый админ. Это офигенный маркер. У Вас линукс? Много разного открытого ПО? Вы правда считаете, что Dovecot, Postfix, Linux, Squid некуда улучшать?
Конечно допиливать нужно но не всегда. На рабочем сервере править конфиги или базу для ускорения работы я бы не стал.
И как в пословице, работа на удалённом маршрутизаторе к дальней дороге.
Всё двояко.
И как в пословице, работа на удалённом маршрутизаторе к дальней дороге.
Всё двояко.
На рабочем сервере править конфиги или базу для ускорения работы я бы не стал.
Рабочих серверов может быть много-много сотен. То есть вы считаете, что если оно худо-бедно работает, то не надо трогать, чтобы не сломалось? Это — подход аникея, который не слишком понимает, как оно устроено внутри.
И как в пословице, работа на удалённом маршрутизаторе к дальней дороге.
Ну вот у меня, наверное, под тысячу удаленных маршрутизаторов, коммутаторов и прочего. Из них минимум 90% находятся далеко от ближайшего компетентного в IT человека. Что же мне теперь, вообще не работать? Или работать так, чтобы выезд человека с консолькой просто не требовался?
Как определяется худо-бедно? Если оно работает и не требует от себя нечего. А вот обновление чего либо на более новое которое под себя обновляет библиотеки с которыми не могут работать другие приложения было и не раз.
И да вы один за тысячи устройствами следите и вечно на них что то делаете и вас никогда нечего не падает, да вы прям герой.
И да вы один за тысячи устройствами следите и вечно на них что то делаете и вас никогда нечего не падает, да вы прям герой.
Если оно работает и не требует от себя нечего
Допустим, некоторый запускаемый ежедневно отчет выполняется за 6 часов. Пользователи этим недовольны. Подкрутив, можно сократить время до 3 часов. Бизнес будет счастлив. А вы этого не делаете, потому что боитесь что-то сломать?
А вот обновление чего либо на более новое которое под себя обновляет библиотеки с которыми не могут работать другие приложения было и не раз.
Поздравляю, вы — аникейщик. Профессионал сначала обкатывает изменение на тесте, потом на препроде, и только потом уже на проде, во время MW, по окончании работ аккуратно протестировав весь функционал. Описанная вами проблема элементарна и вылавливается еще на тесте.
И да вы один за тысячи устройствами следите и вечно на них что то делаете и вас никогда нечего не падает, да вы прям герой.
Не один, конечно, есть еще один коллега, так что выходит где-то по 500 на рыло :)
А так — да, обычно ничего из-за внесенного изменения не падает. Ну ладно, может быть, раз в год кто-то из нас накосячит, но как правило ничего серьезного. Я сейчас, конечно, говорю о тех проблемах, которые вылезают за рамками согласованного окна обслуживания.
Причем серверным админам-то проще всего. Вам для создания реплики прода обычно достаточно склонировать виртуалку. Мне же в идеале надо бы закупить оборудования на сотни килобаксов и поставить его греть воздух в лабе, принося пользу от силы раз в пару месяцев. Потому большинство косяков я вылавливаю именно на проде, после изменения чего-либо без предварительного тестирования, учитывающего индивидуальные особенности и баги железок и софта. И, несмотря на это, обычно все проблемы всё равно укладываются в MW.
Допустим, некоторый запускаемый ежедневно отчет выполняется за 6 часов. Пользователи этим недовольны. Подкрутив, можно сократить время до 3 часов. Бизнес будет счастлив. А вы этого не делаете, потому что боитесь что-то сломать?
Вот только это делается в обратную сторону: кто-то обнаруживает проблему (либо бизнес, которому лень шесть часов ждать, либо админ, который обнаруживает излишнюю загрузку инфраструктуры на эти шесть часов), озвучивает ее, описывает, поднимает (если сразу понятно решение — то вместе с ним) до ответственного за принятие решений, тот говорит, править, или нет (если решения еще нет — то искать решение или нет), и только потом делается «подкрутка», причем — как вы верно сказали — на нескольких контурах последовательно, причем по стандартной процедуре деплоя.
Вероятно, вы именно это и имели в виду, но это не то, что имел в виду minoro, когда писал свое «На рабочем сервере править конфиги или базу для ускорения работы я бы не стал».
Вот только это делается в обратную сторону: кто-то обнаруживает проблему
У нас есть множество офисов, где вход в систему занимает по 20 минут (сотни миллисекунд задержки до контроллеров домена, небольшие потери на радиорелейке, пара мегабит полосы на всех). Бизнес не считает это проблемой. Точно так же формирование определенных отчетов за 6 часов может не считаться проблемой, к этому все привыкли, но ускорение процесса в два раза (или даже на четверть) принесет приличный профит.
Может, сам отчет делает select * from *… Я встречался с одним SQL запросом, который весит 5 мегабайт. Вроде даже где-то в переписке сохранился. Я не вру — 5 мегабайт текста. Запрос, конечно, в итоге работал и давал нужный результат…
но это не то, что имел в виду minoro, когда писал свое «На рабочем сервере править конфиги или базу для ускорения работы я бы не стал».
Мне кажется, именно то — «Конечно допиливать нужно но не всегда». Я очень часто сталкиваюсь с подходом «работает — не трожь». Даже если не сказать чтобы хорошо работает. Люди не понимают, как оно устроено, и боятся это трогать, потому что если сломают, то будет только хуже. Да, любое изменение в проде — это риск, но это значит лишь что этот риск надо учитывать. Боитесь, что полезное обновление сломает совместимость компонентов, и по каким-то причинам нельзя заранее это проверить? Берется 8-часовое окно, 2 часа на само обновление, 4 часа на тщательное тестирование всего функционала скриптами и руками, еще 2 часа на случай необходимости отката.
ускорение процесса в два раза (или даже на четверть) принесет приличный профит.
Вы так считаете? Озвучьте это начальству/РП, включая затраты и риски.
Берется 8-часовое окно, 2 часа на само обновление, 4 часа на тщательное тестирование всего функционала скриптами и руками, еще 2 часа на случай необходимости отката.
Это когда (а) система позволяет восьмичасовые периоды недоступности и (б) 4 часов достаточно на тщательное тестирование всей функциональности.
Вы так считаете? Озвучьте это начальству/РП, включая затраты и риски.
Так ведь и озвучивается.
Это когда (а) система позволяет восьмичасовые периоды недоступности и (б) 4 часов достаточно на тщательное тестирование всей функциональности.
Ну у нас периодически выкатываются подобные изменения. Затрагивается одновременно несколько десятков систем, участвуют сотрудники нескольких подразделений, другие на подхвате. В плане работ в среднем от 50 до 100 пунктов. Отдельный человек координирует выполнение всего этого дела. 4-х часов на тестирование обычно более чем. Если за это время проблема не выявлена, то скорее всего она вылезет далеко не сразу и лишь при определенной фазе луны.
Однажды я был свидетелем того, как один из крупнейших банков мигрировал депозиты с одной системы на другую, с полной остановкой процессинга. Это когда в огромной переговорке выставляются столы по кругу, за ними до утра сидит несколько десятков администраторов (включая тех, которые по плану не нужны, но могут внезапно пригодиться, те же сетевики например), между ними бегают секретарши с кофе, а председатель правления в это время дома страдает от бессонницы. И ничего, справились, ничего в процессе не потеряв. Думаю, по сравнению с этим любые другие работы покажутся мелочью.
Да и вообще, в большинстве случаев можно построить такую цепочку:
«Система не позволяет восьмичасовой даунтайм в период наименьшей нагрузки» => «сервис не резервирован как надо» => «сервис не относится к высокому классу критичности» => «система, являющаяся компонентом сервиса, все-таки позволяет восьмичасовой даунтайм в час наименьшей нагрузки».
Так ведь и озвучивается.
Значит, идет по описанному мной маршруту.
4-х часов на тестирование обычно более чем. Если за это время проблема не выявлена, то скорее всего она вылезет далеко не сразу и лишь при определенной фазе луны.
К сожалению, это не так (если, конечно, под «тестированием» вы подразумеваете не «запустим всех пользователей в боевом режиме»), по крайней мере, в тех системах, с которыми я работал.
Да и вообще, в большинстве случаев можно построить такую цепочку:
Это в идеальном мире. А в реальном вполне бывает так что даунтайм система не позволяет, но при этом у нее вообще нет резервирования (да-да, именно так: business-critical-система без резервирования).
Это в идеальном мире. А в реальном вполне бывает так что даунтайм система не позволяет, но при этом у нее вообще нет резервирования (да-да, именно так: business-critical-система без резервирования).
И руководство в курсе такой ситуации и готово терять деньги в случае аппаратного выхода из строя этой системы? Либо система не критична и можно выделить окно обслуживания, которое должно быть по регламенту, либо эта критичная система — домашний компьютер владельца овощного ларька, ни в одном энтерпрайзе не встречал отсутствия резервирования критичных узлов, во первых ни один вменяемый архитектор такой проект не подпишет, во вторых эта ситуация моментально попадет на стол к главе департамента безопасности ибо это дыра угрожающая бизнесу.
Либо система не критична и можно выделить окно обслуживания, которое должно быть по регламенту, либо эта критичная система — домашний компьютер владельца овощного ларька, ни в одном энтерпрайзе не встречал отсутствия резервирования критичных узлов,
Одно короткое слово: «госуха». Когда человек, принимающий решения, не рискует собственными деньгами и доходами при отказе системы.
Вы, может быть, и не встречали, а для меня это горькая реальность последние несколько лет.
Значит, идет по описанному мной маршруту.
Конечно. В итоге согласуется и выполняется.
К сожалению, это не так
Смоук тестирование, плюс нагрузочное тестирование скриптами, весьма достоверно эмулирующими действия пользователей, плюс запуск небольшого числа реальных пользователей с внимательным анализом результата.
Если механизм отлажен, то 4 часа — это верхняя оценка времени для не слишком масштабного изменения. Обычно можно за час-два управиться.
business-critical-система без резервирования
Business critical система априори позволяет даунтайм. От ее остановки сам бизнес не остановится. Вот с mission critical сложнее, но и там обычно даже полная остановка бывает допустимой.
Если в вашем реальном мире система класса business critical и выше не имеет резервирования… Ну что же, либо не согласовавший закупку необходимого железа и софта бизнес, либо архитектор этой системы является идиотом. Скорее, последнее. Это, конечно, если нарушение или остановка работы компании на несколько часов посреди дня считается катастрофой. Если нет (а бывает и такое), то другой разговор.
Смоук тестирование, плюс нагрузочное тестирование скриптами, весьма достоверно эмулирующими действия пользователей,
И снова идеальный мир. Конечно, встречающийся, но не так часто, как хотелось бы.
Это, конечно, если нарушение или остановка работы компании на несколько часов посреди дня считается катастрофой.
На самом деле, ситуация забавнее. Если система посередь дня встанет, то немедленно будут звонки, разборки, стояние над душой и так далее. Но при этом денег (и ресурсов) на организацию резерва — никто не даст. И восьмичасовой простой ради обслуживания тоже не разрешат.
Ну если вы говорите про госконторы, то это такой местный филиал ада, и в масштабах страны (и тем более — всего мира) редкое исключение. Все-таки компании, не заинтересованные в своей эффективной работе, редко встречаются.
Да и госконторы разные бывают. Некоторые разбрасываются деньгами направо и налево — где-то слышал я про одну, купившую первоклассные массивы вроде на десяток миллионов долларов, и уже после того, как их доставили, администраторы ломали голову над «на кой черт оно нам надо», «что на них перетащить» и «как организовать миграцию с минимальным ущербом».
Да и госконторы разные бывают. Некоторые разбрасываются деньгами направо и налево — где-то слышал я про одну, купившую первоклассные массивы вроде на десяток миллионов долларов, и уже после того, как их доставили, администраторы ломали голову над «на кой черт оно нам надо», «что на них перетащить» и «как организовать миграцию с минимальным ущербом».
в масштабах страны (и тем более — всего мира) редкое исключение.
За мир не скажу, а в конкретно взятой стране сейчас госзаказы составляют неслабую долю рынка IT (особенно в денежном выражении). И, что характерно, это сравнительно стабильные деньги.
Некоторые разбрасываются деньгами направо и налево — где-то слышал я про одну, купившую первоклассные массивы вроде на десяток миллионов долларов, и уже после того, как их доставили, администраторы ломали голову над «на кой черт оно нам надо», «что на них перетащить» и «как организовать миграцию с минимальным ущербом».
И снова все не совсем так. Одна и та же контора может сначала купить весьма недешевое оборудование (которое никак не вяжется в внутрикорпоративную архитектуру), а потом три года пытаться придумать, как его применить; и та же контора может не давать денег на плановое расширение серверной фермы под активно работающую систему — просто потому, что оборудование ложится в некий согласованный «план закупок и развития», а расширение фермы — нет.
Ну я принципиально с такими организациями не контактирую, так что, по счастью, многих деталей не знаю :) Предпочитаю коммерческие структуры, где порядка больше, и где инфраструктурные админы могут забанить развитие и расширение сервисов по причине «нужно закупать новое оборудование», и это оборудование будет закуплено.
Спасибо хоть таким званием наградил мне профессионал. А то я прям расстроился.
Как уже ниже в комментах описано, это вам говорят где есть узкие места то и исправляете.
И да если так всё у вас ровно, посоветуйте тогда способ полного дубля рабочей машины, ну библиотеки версии и прочее. Честно без сарказма был бы благодарен.
Как уже ниже в комментах описано, это вам говорят где есть узкие места то и исправляете.
И да если так всё у вас ровно, посоветуйте тогда способ полного дубля рабочей машины, ну библиотеки версии и прочее. Честно без сарказма был бы благодарен.
И да я не буду трогать то что не знаю как оно работает. Есть софт без документации и который не поддерживается и программисты уходят.
А вас по описанию особенно по обновлению с кучей админов прям идеал какой то, увы не каждому такое дано и не у каждого админа даже помощники есть.
А вас по описанию особенно по обновлению с кучей админов прям идеал какой то, увы не каждому такое дано и не у каждого админа даже помощники есть.
Не обращайте внимания. Такие товарищи встречаются. Чесать языком, как должно быть правильно и что нужно делать, они умеют прекрасно, а когда нужно сделать, тут уже разговор другой начинается. Я уже молчу, если у товарища руки чешутся, чтобы покрутить что-то на продакшен серверах.
Я уже молчу, если у товарища руки чешутся, чтобы покрутить что-то на продакшен серверах.
Так я о том и говорю. Аникей не знает, как работает его система и как ее быстро поднять, если она сломается. Он не умеет оценивать риски, так как мало опыта. У него нет мониторинга на уровне приложения (а то и на уровне сети, встречается и такое). Если возникает проблема, аникей паникует и судорожно закапывается в гугл и форумы. Потому аникей старается никогда ничего не менять на проде, чтобы нечаянно ничего не сломать. Даже когда по его мнению работает оно плохо. Даже когда изменение нужно внести сейчас, иначе оно через неделю может совсем упасть.
А вот скажем товарищи, умеющие подкрутить что-то на продакшн ораклиных базах (которые обычно встречаются только в крупных компаниях, и на которых крутятся архикритичные таблицы), причем так, чтобы оно не только не упало, но и начало работать куда лучше прежнего, получают за этот навык астрономические по меркам аникея деньги. А то ведь много там всяких кнопок и рычагов, которые не документированы и трогать которые рекомендовано исключительно сотрудникам вендора.
Как уже ниже в комментах описано, это вам говорят где есть узкие места то и исправляете.
Так оно не работает. Более того — когда бизнес сообщает службе IT о проблемах в IT инфраструктуре, это вообще полный абзац. Должно быть «IT сообщает бизнесу об устранении проблемы еще до того, как бизнес сообразил, что какая-то фигня происходит».
посоветуйте тогда способ полного дубля рабочей машины, ну библиотеки версии и прочее.
Вам не знакомо слово «виртуализация»? Снять снапшот, скопировать файлы виртуалки на другой хост, там запустить. Где этим всерьез озаботились — есть даже тестовая сеть с адресацией как на проде, чтобы можно было разом склонировать например и сервер приложений, и СУБД, без необходимости менять адресацию. Благо лишних денег это не стоит.
Есть софт без документации и который не поддерживается и программисты уходят.
Если этот софт критичен для бизнеса, то это — колоссальный риск, грозящий разорением.
увы не каждому такое дано и не у каждого админа даже помощники есть.
Потому я и говорю, что «многорукий шива» должен быть переходным этапом в жизни администратора. Сначала он работает по интуиции, абы как, а потом узнает, как надо работать на самом деле и начинает удивляться, как инфраструктура, за которую он отвечал, умудрялась не падать каждый день, а падала только раз в неделю…
Знакомо слово виртуализация, но сделать образ с рабочей машины к которой нет доступа физически я не представляю как.
В общем вы представляете видимо для себя кто работает один а не в команде админов, как низкого админа классом. Но увы не каждая фирма походит на Газпром или Сбербанк.
В общем вы представляете видимо для себя кто работает один а не в команде админов, как низкого админа классом. Но увы не каждая фирма походит на Газпром или Сбербанк.
но сделать образ с рабочей машины к которой нет доступа физически я не представляю как.
Вы администрируете сервис, который работает на машине, к которой вы не имеете доступа? Хм… Вот допустим она внезапно перестала отзываться на пинги/RDP/SSH. Что будете делать?
В общем вы представляете видимо для себя кто работает один а не в команде админов, как низкого админа классом.
Честно? Да. Если человек способен в одиночку справиться со всей информационной инфраструктурой, то у него не тот уровень задач, не тот уровень ответственности, не те требования к знаниям. Я сам через это проходил. В те времена я считал себя крутым специалистом, раз на мне лежала ответственность за всё, а сейчас я считаю, что я был обыкновенным безмозглым аникеем, причем куда хуже большинства присутствующих.
Является ли человек, увлеченный картингом и показывающий неплохие результаты, низкого класса гонщиком? Само собой. Особенно в сравнении с пилотами F1. Может ли этот любитель картинга со временем перейти в класс F1? Всё зависит от него, почти все с этого начинали. Является ли тот факт, что человек гоняет на картах, оскорбительным или унизительным? Нет, хотя если он хочет всю жизнь заниматься этим профессионально (а не просто раз в неделю покататься с друзьями), то возникают определенные вопросы.
Видимо это особенность русского менталитета, всем тыкать носом что вы ниже если сам добился каких либо результатов, что в бизнесе что в карьере. И тут вижу тоже самое.
И да нужно говорите что нужно быть узким специалистом, а сами говорите и коммутаторы ковыряете и сервера за одно. Не порядок.
И да нужно говорите что нужно быть узким специалистом, а сами говорите и коммутаторы ковыряете и сервера за одно. Не порядок.
Да причем тут менталитет? Какое еще тыканье носом?
Вот судя по вашему профилю, ваш основной интерес лежит в сфере баз данных. Есть возражения, что сидящие неподалеку от моего рабочего места ораклоиды, поддерживающие инфраструктуру для наиважнейших сервисов крупной организации, знают и умеют больше вашего, хотя бы исходя из цены их ошибок (вплоть до полного разорения организации)? Или что юниксоиды, отвечающие за сервера, на которых крутится в том числе ораклы, лучше вашего знают *NIX часть?
Что же это за специалист, не способный решать corner case'ы, связанные с его зоной ответственности? Если бы я, скажем, немного не знал *NIX территорию, а наши юниксоиды не понимали бы значения слова «VLAN» — все говорили бы на разных языках, никто никого не понимал бы, и возникла бы крайне печальная ситуация. Любые проблемы решались бы безумное количество времени.
А по факту ко мне от коллег из не имеющих отношения к сети подразделений нередко приходят запросы вида «добавь VLANы по приложенному списку на такой-то транк такого-то свитча». Они понимают значение каждого из этих слов, они понимают сетевые требования для работы их сервисов, это экономит массу ресурсов на выяснение «что тебе надо-то» и на диагностику проблем «поднял сервер, а он не пингуется». Они обладают достаточными знаниями, чтобы самостоятельно вносить изменения в конфигурацию портов в сторону их систем на дорогущем сетевом оборудовании. Я бы мог выполнять базовые операции на их системах. Но каждый — специалист в своей области, у каждого мозги и время не резиновые, потому каждому надо глубоко знать свою область и поверхностно — смежные. Знать глубоко всё или хотя бы многое невозможно. Знать поверхностно всё — это и есть тот самый аникей, промежуточный этап развития администратора, пока он не выберет себе специализацию и не начнет развиваться в одном направлении.
Если все еще по какой-то причине обижаетесь — представьте себя любителем гонок на картах, и попробуйте вообразить собственную реакцию на фразу «раллийный гонщик круче как гонщик». Обидно? По-моему, нет, я бы на такое точно не обиделся. Это просто ориентир, к которому можно двигаться, если есть желание профессионально развиваться.
Вот судя по вашему профилю, ваш основной интерес лежит в сфере баз данных. Есть возражения, что сидящие неподалеку от моего рабочего места ораклоиды, поддерживающие инфраструктуру для наиважнейших сервисов крупной организации, знают и умеют больше вашего, хотя бы исходя из цены их ошибок (вплоть до полного разорения организации)? Или что юниксоиды, отвечающие за сервера, на которых крутится в том числе ораклы, лучше вашего знают *NIX часть?
а сами говорите и коммутаторы ковыряете и сервера за одно.
Что же это за специалист, не способный решать corner case'ы, связанные с его зоной ответственности? Если бы я, скажем, немного не знал *NIX территорию, а наши юниксоиды не понимали бы значения слова «VLAN» — все говорили бы на разных языках, никто никого не понимал бы, и возникла бы крайне печальная ситуация. Любые проблемы решались бы безумное количество времени.
А по факту ко мне от коллег из не имеющих отношения к сети подразделений нередко приходят запросы вида «добавь VLANы по приложенному списку на такой-то транк такого-то свитча». Они понимают значение каждого из этих слов, они понимают сетевые требования для работы их сервисов, это экономит массу ресурсов на выяснение «что тебе надо-то» и на диагностику проблем «поднял сервер, а он не пингуется». Они обладают достаточными знаниями, чтобы самостоятельно вносить изменения в конфигурацию портов в сторону их систем на дорогущем сетевом оборудовании. Я бы мог выполнять базовые операции на их системах. Но каждый — специалист в своей области, у каждого мозги и время не резиновые, потому каждому надо глубоко знать свою область и поверхностно — смежные. Знать глубоко всё или хотя бы многое невозможно. Знать поверхностно всё — это и есть тот самый аникей, промежуточный этап развития администратора, пока он не выберет себе специализацию и не начнет развиваться в одном направлении.
Если все еще по какой-то причине обижаетесь — представьте себя любителем гонок на картах, и попробуйте вообразить собственную реакцию на фразу «раллийный гонщик круче как гонщик». Обидно? По-моему, нет, я бы на такое точно не обиделся. Это просто ориентир, к которому можно двигаться, если есть желание профессионально развиваться.
Было от вас уже про карт. И я не обижаюсь.
Но по вашему высокомерию то что я описал выше похоже очень походит на вас. Не зная человека и его занятия и профиль работы очень легко определяете его.
Пишете что нужно всё одним заниматься а тут же оказывается что у вас специалисты знают не только что их касается. Да и вас так же. По сути тем же самым по вашему эникеем можно назвать кого угодно кто знает как решить больше одной задачи.
Но по вашему высокомерию то что я описал выше похоже очень походит на вас. Не зная человека и его занятия и профиль работы очень легко определяете его.
Пишете что нужно всё одним заниматься а тут же оказывается что у вас специалисты знают не только что их касается. Да и вас так же. По сути тем же самым по вашему эникеем можно назвать кого угодно кто знает как решить больше одной задачи.
Не зная человека и его занятия и профиль работы очень легко определяете его.
Одной фразы «не менять конфиги боевых серверов» вполне достаточно :) Нет, менять конфиги боевых серверов надо. И надо точно знать, на что влияет изменение и как свести риск негативных последствий к минимуму.
И удаленно править конфиги маршрутизаторов необходимо — тоже заранее спланировав риски и подстраховавшись, чтобы той самой дальней дороги не потребовалось. Вопреки распространенному мнению, что цискины железо и софт чертовски надежны и стабильны, практика показывает, что это ой как далеко от правды, и эти железки периодически самые потрясающие фортели выкидывают. Ну что же, значит, надо прокачивать скилл предсказательства, заранее пытаться угадывать, какое изменение наверняка пройдет без проблем, а какое чревато выявлением нового бага и нарушением работы сервиса (даже если всё делается строго по документации).
Пишете что нужно всё одним заниматься а тут же оказывается что у вас специалисты знают не только что их касается.
Не вижу противоречия. Я писал, что профессионалу надо глубоко знать что-то одно. Если больше одного, то это круто, но встречается исключительно редко. То, что профессионал не должен знать смежные темы, я не писал. Еще как должен. Есть у меня коллеги, которые отлично понимают свое направление, но ни шагу в сторону. Местами печальное зрелище — отсутствие подобных знаний приводит к фейлам даже по своей теме.
Однако, если человек по работе занимается сразу десятком совершенно разных направлений (не на уровне «что-то слышал» как я в случае *NIX или юниксоиды в случае сети), то обычно не следует ждать от такого человека глубокого понимания ни одной из этих тем. В тех небольших масштабах, с которыми он сталкивается, глубокое понимание банально не требуется.
А вот вы знаете что-то на достаточном уровне, чтобы я мог порекомендовать вас коллегам, и вы бы прошли многочасовое техническое интервью? MS SQL (есть отдельные люди, работающие исключительно с ним)? Oracle (тоже отдельные люди)? *NIX опять же, т.е. Solaris, AIX и ряд других систем?
не понимаю я всё таки немного зачем ковырять то что и так хорошо работает. Нужно конечно пробовать разные конфигурации использовать и смотреть что из этого выйдет но не боевом сервере.
NIX знаю, но у каждого суждения о достаточном знании рознятся. И да всё знать тоже не возможно, тебе зададут вопросы на которых ты не знаешь ответы и всё ты нуб. Но так же и ты можешь задать вопросы на которые они не ответят. И вот каждый думает что противоположенный человек дерево в своих знаниях.
NIX знаю, но у каждого суждения о достаточном знании рознятся. И да всё знать тоже не возможно, тебе зададут вопросы на которых ты не знаешь ответы и всё ты нуб. Но так же и ты можешь задать вопросы на которые они не ответят. И вот каждый думает что противоположенный человек дерево в своих знаниях.
не понимаю я всё таки немного зачем ковырять то что и так хорошо работает
Да хоть банальные security патчи ставить раз-два в месяц.
Опять же, вот оно, различие в подходах. Если вы отвечаете за какую-нибудь никому не нужную домашнюю страничку, то подход «поднял и забыл на много лет» работает. Если же речь идет, допустим, о фронтенде PayPal, то ситуация резко меняется, и изменения конфигурации боевых систем начинают происходить на ежедневной основе, иначе похакают.
тебе зададут вопросы на которых ты не знаешь ответы и всё ты нуб.
Смотря какие вопросы. Есть такие, незнание ответа на которые гарантирует некомпетентность, и можно сразу распрощаться. Грубо говоря — если вы неправильно или вообще не объяснили смысл load average. Да и «не знаю» — понятие растяжимое. Можно не знать ответ, но знать, где этот ответ найдется за несколько секунд, что практически равносильно знанию ответа. Конечно, это относится скорее к дефолтным номерам портов не самых известных сервисов, а не к load average…
Во первых, причем тут рабочая машина?
Во вторых, нужно серверы ставить воспроизводимо, чтобы всегда можно было поднять полную копию за конечное время, а не вытачивать напильником.
В третьих, если сервер настраивался несколькими поколениями админов, и к вам он пришел в неизвестном состоянии можно по-немногу, по-одному сервису, привести их в нормальный человеческий вид, который мы более-менее воспроизводимо сможем уже повторить на новой железке и проверить, правильно мы все описали.
В четвертых, на самый крайний случай (когда нужно быстро создать копию, а все приводить в порядок некогда), есть rsync.
Встречается иногда, конечно, определенный софт типа шифрованных платных CMS для PHP, многолетней давности с прекратившейся поддержкой — с ним беда, да, но это довольно редкий случай.
Во вторых, нужно серверы ставить воспроизводимо, чтобы всегда можно было поднять полную копию за конечное время, а не вытачивать напильником.
В третьих, если сервер настраивался несколькими поколениями админов, и к вам он пришел в неизвестном состоянии можно по-немногу, по-одному сервису, привести их в нормальный человеческий вид, который мы более-менее воспроизводимо сможем уже повторить на новой железке и проверить, правильно мы все описали.
В четвертых, на самый крайний случай (когда нужно быстро создать копию, а все приводить в порядок некогда), есть rsync.
Встречается иногда, конечно, определенный софт типа шифрованных платных CMS для PHP, многолетней давности с прекратившейся поддержкой — с ним беда, да, но это довольно редкий случай.
как раз о таких случаях и речь. Так же обновление php в котором могут быть убраны функции используемые по всему коду.
Я использую rsync для бекапов и конфигов.
Я вот всё не очень понимаю, если всё работает на должном уровне зачем это ковырять я понимаю увеличить фукционал или дырку закрыть.
Я использую rsync для бекапов и конфигов.
Я вот всё не очень понимаю, если всё работает на должном уровне зачем это ковырять я понимаю увеличить фукционал или дырку закрыть.
Если действительно все работает и есть запас по ресурсам, а также вы можете разбуженным в 4 часа утра воссоздать полный функционал сервера и поднять бэкапы, то действительно, ковырять не нужно. Просто бывает ситуация, когда есть тонны древнего кода, на костылях и подпорках, оно как-то работает и в принципе всех устраивает, но в случае сбоя никто не знает как это поднять, бэкапы есть, но на восстановление не проверялись и не восстанавливаются, а надо срочно восстановиться, вот тут тот, кто не ковырял бежит в аптеку за вазелином, а тот кто разобрался что к чему и как, неспешно по-порядку все это дело поднимает. Если вы готовы одномоментно потерять любую систему и сможете в не критичное время все это воссоздать на резерве — вам ковырять дальше ни к чему.
Потому что захотите вы, например, переехать на соседний хостинг, и не сможете: старых версий дистрибутивов уже нет, сопутствующий софт типа веб-админок тоже обновился и реальным выходом в таком случае останется только полная переустановка сервера.
Если это случаи в компании единичные, и с ними ничего поделать нельзя (хостим говносайт заказчиков, в который никто денег не вложит) нужно делать их документированными и воспроизводимыми — чтобы знать о проблемах заранее и быть к ним готовым.
Если такое в компании встречается часто, значит это действительно скорбный бизнес, нужно или его перестраивать почти полностью, или уходить в другую компанию.
Если это случаи в компании единичные, и с ними ничего поделать нельзя (хостим говносайт заказчиков, в который никто денег не вложит) нужно делать их документированными и воспроизводимыми — чтобы знать о проблемах заранее и быть к ним готовым.
Если такое в компании встречается часто, значит это действительно скорбный бизнес, нужно или его перестраивать почти полностью, или уходить в другую компанию.
Падает у всех иногда, но авторолбеки никто не отменял, ну и думать перед тем как вкоммитить настройку не проверенную на стенде, если это не банальность какая-то. Не трогать иногда чревато, патчи безопасности, нужные фичи, глубокий тюнинг и т.д. Бояться своей же системы, тогда зачем админ нужен, если он не знает как оно все работает. Для физического доступа к большей части железа, с которым работаю мне понадобится самолет и 12 часов перелета только в одну сторону, так что забить на все и молиться на святую корову «работающий сервер». Тем кто работает исключительно с серваками чуть проще, у них есть IPMI, а вот сетевикам надо предварительно хорошо думать, хотя сейчас уже и сетевики радуются возможности commit confirmed на боевых маршрутизаторах без резерва.
Ну так привел одну компанию, получил рекомендации, закрыл проект пошел в следующую более крупную и интересную. Админ все равно будет нужен, планировать расширение мощностей, архитектура сети и так далее. Сегодня обслуживаете 40 серверов завтра уже 40 000, другой уровень другие задачи автоматизации. Если вы из СПБ, почему не пошли например в Яндекс, они регулярно админов ищут и задачи там для админа интересные (немного общался).
Да, в Яндексе есть крутые вакансии. А также есть целая куча хостеров с крутыми задачами и тыщами сервером каждый :)
Вопрос автору: Насколько просела зарплата после перехода в программисты? Ну и регион пожалуйста укажите где проживаете.
Сам админ, но еще пожалуй один из плюсов работы программистом, который я вижу, это отсутствие ночных звонок в 3 утра.
Поясню: Да, есть тех поддержка, которая 24\7 и решает мелкие проблемы. Но есть проблемы, которые тех поддержка решить не может.
Сам админ, но еще пожалуй один из плюсов работы программистом, который я вижу, это отсутствие ночных звонок в 3 утра.
Поясню: Да, есть тех поддержка, которая 24\7 и решает мелкие проблемы. Но есть проблемы, которые тех поддержка решить не может.
Резервирование важных сервисов — не, не слышал. По какой причине могут позвонить в 3 часа утра, кроме прямого попадания метеорита в техузел? За крайний год ночью вставал 2 раза оба планово для обслуживания и обновления центральных маршрутизаторов, если это причина для ухода их профессии то я не знаю как вы встретите первый дедлайн у программистов. Опишите кейсы, для чего нужно вставать ночью часто?
Поработайте в интеграторе когда на вашей группе висят 200+ систем и ты прописан в маршрутном листе звонков для 30 из них.
Тогда ночные звонки будут обязательно.
Особенно часто это последеплойные сюрпризы.
Тогда ночные звонки будут обязательно.
Особенно часто это последеплойные сюрпризы.
Вы в интеграторе первая линия? Тогда сочувствую, растите быстрее, освобождайте место молодым. Нужен кто-то из опытных 24/7, не вопрос пилите сутки на смены, замечательно пилится по 8 часов на человека, часовых поясов много либо вахтовый метод. Не нормированные переработки — это страшная авария техногенного характера, захват инопланетянами или в этом роде — оплачивается отдельно по тарифу х3 или выше, а деплой и баги после него — штатная ситуация, дежурный инженер должен их решать в рабочую смену, вы же не на 200+ систем сразу деплоите.
Не первая линия.
У нас распилены не сутки, а сервисы. Например за эти 10-50 отвечает один человек, за эти другой и так далее.
«А деплой и баги после него — штатная ситуация, дежурный инженер должен их решать в рабочую смену» — а в нерабочее время что с багами делать? А если деплой неправильно прошел? Бросить все и откатывать назад — специфика фирмы не та, нельзя.
У нас распилены не сутки, а сервисы. Например за эти 10-50 отвечает один человек, за эти другой и так далее.
«А деплой и баги после него — штатная ситуация, дежурный инженер должен их решать в рабочую смену» — а в нерабочее время что с багами делать? А если деплой неправильно прошел? Бросить все и откатывать назад — специфика фирмы не та, нельзя.
Резервирование важных сервисов — не, не слышал. По какой причине могут позвонить в 3 часа утра, кроме прямого попадания метеорита в техузел?
Ох… Практика показывает, что сколько ни резервируй — всегда где-то вылезет неожиданный SPOF. Если не на собственной сети, то у трех разных провайдеров с разными ОПМ до важной площадки.
Ну вот пример из опыта: на ровном месте лупбек одной из железок ядра перестал анонсироваться в IGP, но не ушел в down. Сам IGP не разваливается — ему этот лупбек по барабану, на нем соседей нет. А вот LDP растерял всех соседей, так как соседи потеряли маршруты до лупбека. В результате весь трафик с метками через это ядро начал блекхолиться из-за развала LSP.
И при этом никто ничего перед аварией не менял. Честно-честно.
Если вы утверждаете, что полностью резервированный сервис не может упасть сам собой посреди ночи — вы, видимо, слишком мало работали с сетями :)
Такие ситуации бывают, но сколько раз у вас такая ситуация была за год? Пальцев 1 руки пересчитать думаю хватит, нам тоже 3 оптики порвали в 1 день с разницей в 2 часа от разных аплинков с разных районов, вероятность штука подлая. Или, например ни с того ни с сего развалилось кольцо через транспорт дружественной сети, тоже никто ничего не трогал. Я не говорю что резервирование всегда работает, но если вы не досыпаете по 3 раза в неделю, то наверное с архитектурой все-же что-то не так.
IGP не на экстримовской железке такой финт выкинул?
<offtop>IGP не на экстримовской железке такой финт выкинул?
</offtop>но сколько раз у вас такая ситуация была за год
По моей части — раз, может — два в год. Но каждый такой случай, конечно, бесит. А еще есть разной степени криворукости коллеги из других подразделений, которые рады свалить косяк своей системы на сеть, приходится лезть и разбираться. Это немного почаще бывает, но тоже не особо, пальцев одной руки хватит.
но если вы не досыпаете по 3 раза в неделю, то наверное с архитектурой все-же что-то не так.
Если 3 раза в неделю, то проблема в ДНК, архитектура — лишь одно из проявлений этой проблемы.
IGP не на экстримовской железке такой финт выкинул?
Обычный шеститонник. Shut / no shut не помогал. Копипаст конфига лупбека, его удаление и пересоздание под копирку помогло. Разумеется, TAC развел руками. Триггер неизвестен, диагностики особой собрано не было. Ну видать типичный «soft parity error».
Дедлайн это дедлайн. Как правило ты понимаешь, что он будет. Да и у админов он тоже есть. А вот, когда тебя чуть ли не с девушки снимают это как-то очень очень печально.
По поводу кейсов: как ниже отписали, что практика показывает, от необычных зависаний не защититься простым резервированием. Ну и разные последеплойные штуки само собой.
По поводу кейсов: как ниже отписали, что практика показывает, от необычных зависаний не защититься простым резервированием. Ну и разные последеплойные штуки само собой.
Соглашусь по всем пунктам. Вообще, если человек вынужден перерабатывать постоянно, а тем более если его постоянно дергают ночью — проблема либо в человеке, либо в организации рабочего процесса.
Мне звонили, правда, не ночью, а с утра в выходной, только один раз — когда горело здание одной из основных серверных. Да и то дозвонились только когда я проснулся, ибо есть у меня привычка ночью выключать звук на телефоне, а ненормированный рабочий день в трудовом договоре не прописан.
Мне звонили, правда, не ночью, а с утра в выходной, только один раз — когда горело здание одной из основных серверных. Да и то дозвонились только когда я проснулся, ибо есть у меня привычка ночью выключать звук на телефоне, а ненормированный рабочий день в трудовом договоре не прописан.
Ненамного, около 15%, учитывая что позиция junior, так что расти есть куда. Спб
Если вы действительно любили админить вам нужно было развиваться в эту сторону дальше, а не держать пачку линукс серверов. Поменять работу например не пробовали? В вашем случае, либо уходить в узкие вещи и становиться экспертом либо devops. Я как раз таки наоборот, всегда не хотел случайно стать программистом. Хотя возможности были. И было сложно выбраться из эникея.
Крутых программистов в России я видел, много. А вот крутых администраторов могу перебрать по пальцам одной руки. Что говорит, безусловно, об отмирании профессии :)
Люто не одобряю такой переход, имхо, для крутого админа уйти в программисты — это падение с Олимпа. Правильный админ должен уметь отлично программировать нужные ему задачи, но скатываться до лабания сайтиков на Python, фи.
Люто не одобряю такой переход, имхо, для крутого админа уйти в программисты — это падение с Олимпа. Правильный админ должен уметь отлично программировать нужные ему задачи, но скатываться до лабания сайтиков на Python, фи.
Сайтики сайтикам рознь и я не сказал что пишу их.
Я сделал этот вывод по ключевым словам «django» / «wsgi» / «frontend». А что пишете? Геораспределенное отказоустойчивое высоконагруженное хранилище как аналог Google Big Table?
Работу крутых программистов видят многие, работу крутого админа вы вряд-ли заметите, она выглядит как все работает так как задумано и другие отделы компании могут даже не знать что у них есть админ и как его зовут. Да и критерий крутости штука относительная, вот как ее посчитать? В количестве серверов — вряд-ли, после определенного количества уже все равно сколько их обслуживать, в количестве проектов — тоже вряд-ли, в минутах даунтайма в год, ну возможно но не для всех админов да и как сказали выше всякое бывает даже с опытными. Остается банально ЗП, ну или я не знаю как отличить крутого админа от заурядного, но набившего руку.
И количество сертификатов.
Ха 3 раза, знаю людей которые получили их гору по брэиндампам из-за формальных требований в фирме к их наличию и привязке бонусов, но при этом ни дня не работали по технологиям этих сертификатов.
Я знаю одного человека, который CCIE^4 (Voice/Security/RS/SP) и еще куча всего по другим направлениям и вендорам. Даже периодически с ним общаюсь. Чертовски грамотный спец. По-моему, нет ничего такого, чего бы он не знал по части цискиного VOIP. По другим направлениям как-то не представлялось возможности оценить его.компетентность, но я верю, что как минимум в рамках курса CCIE (который на самом деле не сказать чтобы уж прям глубокий) он всё перечисленное знает, даже если без боевого опыта, на лабах. Опять же, бывают corner-case'ы, когда его основное направление (voice) пересекается с другими.
Про него говорят, что когда он не изучает что-то новое, у него начинается ломка. Человек зависим от знаний. Прекрасное заболевание — у меня явно схожий диагноз, только в более легкой форме, и это заболевание, по-моему, должно иметься у любого работающего в IT человека.
Про него говорят, что когда он не изучает что-то новое, у него начинается ломка. Человек зависим от знаний. Прекрасное заболевание — у меня явно схожий диагноз, только в более легкой форме, и это заболевание, по-моему, должно иметься у любого работающего в IT человека.
Как? Очень просто — побеседовать хотя бы 10 минут с человеком. И сразу станет понятно, кто крутой админ :)
И какими крамольными знаниями должен он обладать, как отличить крутого «сетевика» от крутого «безопасника», «ЦДНщика» или «телефониста»? Что за универсальный вопрос спросить. Да даже внутри одной специализации есть столько разных направлений и углублений что не поймешь. Тем более собеседующий сам должен быть не слабо в теме иначе компетентный ответ может посчитать за неправильный.
Есть же шутка про вопрос о браузере.
Правда она не всеобъемлюща, но всех тех кто работает с вебом касается
Правда она не всеобъемлюща, но всех тех кто работает с вебом касается
Озвучьте шутку, я не в теме — интересно.
У меня есть браузер.
Я написал в адресной строке yandex.ru, расскажите максимально подробно что произойдет после того как вы нажмете энтер.
Фронтэнд девелопер будет рассказыветь про работу браузера и показ странички
Бекенд девелопер расскажет про работу приложения
Админ расскажет про работу веб-сервера
Сетевик про работу сети в это время
ну и т.д.
Я написал в адресной строке yandex.ru, расскажите максимально подробно что произойдет после того как вы нажмете энтер.
Фронтэнд девелопер будет рассказыветь про работу браузера и показ странички
Бекенд девелопер расскажет про работу приложения
Админ расскажет про работу веб-сервера
Сетевик про работу сети в это время
ну и т.д.
админ начнет с DNS
О, это дивный вопрос и я его очень люблю :) Полный ответ на него у знакомого тру админа занял около 1 часа, с применением DHCP, DNS, TCP/IP, BGP и еще доброй сотни имен демонов и протоколов :)
Ваш запрос будет обработан браузером, который начнет выяснять куда необходимо обратиться, через сетевую карту, цепочку коммутаторов и маршрутизаторов будет отправлен пакет (модель OSI и структуру пакета опустим) изначально на DNS сервер который, если кеширующий запросит его далее вплоть до корневого, либо отдаст из кеша (протокол чаще всего UDP порт 53), придет ответ в виде IP, затем на этот IP через цепочку свичей и маршрутизаторов пойдет запрос на установление TCP соединения, который снова пройдет цепочку железяк, фаирвол и попадет на WEB сервер, если он «слушает» на данном порту в большинстве случаев это будет фронтенд сервер, распределяющий нагрузку на бэкенды, фронтенд установит первичное открытое соединение (тут длинное описание тройного рукопожатия) запросит у бекенда наличие данной страницы, бэкенд обратится к своей базе… (если человек нудный вы получите дипломную работу листов на 200 при этом человек сдавший недавно какие-нибудь ИСС ответит намного подробней чем админ, так что тоже не показатель.)
А как назвать того, кто расскажет про всю цепочку событий?
написал в адресной строке yandex.ru, расскажите максимально подробно что произойдет после того как вы нажмете
Это классика :)) я на него сам 8 лет назад отвечал, и не один раз задавал
У меня было довольно много собеседований по вот этой вакансии spb.hh.ru/vacancy/10898085, где-то полсотни или больше. Админ — это довольно размытое понятие, к нам приходят разные люди — от почти без опыта до «20 лет стажа в тяжелом продакшене». Да, у них разные сферы и разный опыт работы, но я считаю, что у администратора — это не главное. А главное в работе администратора:
1) Умение учиться
2) Умение доводить работу до конца
3) Отвественность за свою работу
4) Доскональное понимание (или желание изучить) систем, с которыми человек работает.
5) Понимание «продакшена»
Если это есть — человек либо уже хороший администратор либо может им стать. Разумеется, список не полный, взял из головы самое основное, но суть я думаю ясна.
1) Умение учиться
2) Умение доводить работу до конца
3) Отвественность за свою работу
4) Доскональное понимание (или желание изучить) систем, с которыми человек работает.
5) Понимание «продакшена»
Если это есть — человек либо уже хороший администратор либо может им стать. Разумеется, список не полный, взял из головы самое основное, но суть я думаю ясна.
Ну одним из отличий является полная автоматизация любых бизнес-процессов, как имеющихся, так и внезапно появившихся новых.
Почти с меня писали. Я тоже был админом, тоже перешел в стан питонистов :)
Я тоже был долгое время админом (в основном виндовым, но без предвзятости, что нужно делал на *nix). И тоже перебрался в разработчики. Я прошел путь от эникея — ИП (аутсорсил фирмы) — штатного админа, и в итоге сменил профессию. На самом деле причина проста. Развиваться в профессиональном плане админу, а точнее нарабатывать реальный опыт, можно только в достаточно крупных городах. В моем городе с большой инфраструктурой можно столкнуться только на заводах (но там адовая бюрократия, полное отсутсвие гибкости, бумагоморательство — получение опыта будет проходить очень долго). Единственный способ набрать опыта — переехать в другой город, а этого у меня в планах нет. Разработчиком куда проще найти удалённую работу, и опыт набить можно независимо от местонахождения. В общем целом, не жалею о своём переходе. Разработчиком мне быть куда интереснее, чем админом.
Я тоже был долгое время админом (в основном виндовым, но без предвзятости, что нужно делал на *nix). И тоже перебрался в разработчики. Я прошел путь от эникея — ИП (аутсорсил фирмы) — штатного админа, и в итоге сменил профессию. На самом деле причина проста. Развиваться в профессиональном плане админу, а точнее нарабатывать реальный опыт, можно только в достаточно крупных городах. В моем городе с большой инфраструктурой можно столкнуться только на заводах (но там адовая бюрократия, полное отсутсвие гибкости, бумагоморательство — получение опыта будет проходить очень долго). Единственный способ набрать опыта — переехать в другой город, а этого у меня в планах нет. Разработчиком куда проще найти удалённую работу, и опыт набить можно независимо от местонахождения. В общем целом, не жалею о своём переходе. Разработчиком мне быть куда интереснее, чем админом.
Вот очень спорно…
Для Админа совершенно не требуется находится в одном помещении с инфраструктурой. Админ и техник это совершенно разные сущности и не надо их смешивать. И крупность города совершенно не ключевой момент. В метрополиях проще найти интересную работу, согласен, но на получение опыта и знаний это никак не влияет.
Для Админа совершенно не требуется находится в одном помещении с инфраструктурой. Админ и техник это совершенно разные сущности и не надо их смешивать. И крупность города совершенно не ключевой момент. В метрополиях проще найти интересную работу, согласен, но на получение опыта и знаний это никак не влияет.
Вы говорите по личному опыту? Я — да. Я искал работу, удалёнщиков вообще не рассматривали. Либо переезд, либо никак. Может удалёнщики и были, но я таких не знаю, хотя крутился в админской тусовке. Под удалённой работой я имею ввиду работу из другого города, а не в том же городе, но из дома.
Опыт имеется живой, а не «построю-ка я идеальную инфраструктуру на виртуальных машинах!». У нас находятся филиалы провайдеров в основном, весь тех. состав почти в головных офисах, местные единицы мест в них были заняты. На крупных предприятиях почти везде инфраструктура была на винде, что исключало получение живого опыта на линуксе. Я могу долго приводить доводы, почему я поступил так, а не иначе.
Опыт имеется живой, а не «построю-ка я идеальную инфраструктуру на виртуальных машинах!». У нас находятся филиалы провайдеров в основном, весь тех. состав почти в головных офисах, местные единицы мест в них были заняты. На крупных предприятиях почти везде инфраструктура была на винде, что исключало получение живого опыта на линуксе. Я могу долго приводить доводы, почему я поступил так, а не иначе.
Скажите это ему opium. Он админ-фрилансер.
Тут сложно.
К примеру, на текущей работе я, находясь в Питере, последнее время в основном занимаюсь серверами в Москве и удаленных филиалах. Ну и могу работать вообще из дома, что и делаю временами. Но — изначально речь об этом не шла, искали именно админа в питерский филиал, а дальше уже так сложилось, что стал заниматься многими другими вещами.
А не так давно хорошая знакомая предлагала мне фактически архитекторскую должность в известной международной компании, но с обязательным условием переезда в Москву как раз по причине того, что им требовался человек, который сможет при необходимости срочно решать проблемы инфраструктуры в том числе и на физическом уровне.
К примеру, на текущей работе я, находясь в Питере, последнее время в основном занимаюсь серверами в Москве и удаленных филиалах. Ну и могу работать вообще из дома, что и делаю временами. Но — изначально речь об этом не шла, искали именно админа в питерский филиал, а дальше уже так сложилось, что стал заниматься многими другими вещами.
А не так давно хорошая знакомая предлагала мне фактически архитекторскую должность в известной международной компании, но с обязательным условием переезда в Москву как раз по причине того, что им требовался человек, который сможет при необходимости срочно решать проблемы инфраструктуры в том числе и на физическом уровне.
Это я всё знаю, и лично проходил. Когда я аутсорсил фирмы, я сперва договаривался, что буду приходить минимум N раз в неделю в контору, а потом всё стекалось к тому, что большую часть работы я делал из дома. В конторе появлялся только по срочным вызовам, ну и для профилактики. Люди понимали, что делать постоянно у них мне нечего, но если бы я пришел и заявил сразу, что я так буду работать — я бы не нашел клиентов. И это только в своём городе.
А теперь представьте, как сложно найти работу в другом городе на удалёнке админу из глубинки. Вроде и я, и работодатель понимаем, что местонахождения значения не имеет, но требуют офис. В общем походил туда-сюда, посмотрел, и решил сменить профессию.
А так да, в Москву и Казань звали на постоянку, но с условием переезда.
У всех свой опыт, у кого — удачный, у кого — не очень, сравнивать смысла нет.
А теперь представьте, как сложно найти работу в другом городе на удалёнке админу из глубинки. Вроде и я, и работодатель понимаем, что местонахождения значения не имеет, но требуют офис. В общем походил туда-сюда, посмотрел, и решил сменить профессию.
А так да, в Москву и Казань звали на постоянку, но с условием переезда.
У всех свой опыт, у кого — удачный, у кого — не очень, сравнивать смысла нет.
Тут еще от специализации зависит. Чуть менее года я, работая в те времена шивой, занимался еще и фрилансом — Asterisk, VoIP и все что около. Там я вообще ни разу ни одного физического сервера вживую не видел, а география заказчиков была — весь СНГ,
Да, так и есть. У меня так случилось, что я в основном имел опыт с виндовыми решениями, вот и был виндовым админом. Линукс изредка попадался под руки, но то было очень редко. VoIP так и не попался ниразу. В основном либо уже была обслуживающая контора, либо хардварные решения которые совсем не требовали перенастройки.
Начинающему админу удаленно никто не доверит инфраструктурой управлять. Он на то и начинающий. Получить опыт и знания не выезжая из родного города можно, но это тяжелее. Элементарно надо больше времени уделить на поиск и больше усилий приложить. А стоит ли это того или нет, каждый сам решает.
Спорно. Это в совсем уж масштабных организациях, имеющих не один собственный ЦОД, могут быть отдельные техники. А чаще всего админ занимается и софтовой, и железной частью инфраструктуры.
Все развивается по спирали, может еще статься вернуться к админству, но в другом качестве. «Частные Облака» тема очень вкусная для крупного бизнеса, а там программист+админ — частая картина. Ну и да, OpenStack на питоне пишется ;)
Вообще в админке иногда даже мозг пухнет от того, сколько нужно знать. Так и хочется выучить фреймворк какой и писать код бесконечно.
Если вы не тащитесь от процесса получения новых знаний и опыта — что вы забыли в администрировании?
Посмотреть и потыркать что-то новенькое всегда интересно. Девелоперам в том числе. Когда дело заходит сделать что-то в продакшен, понимаешь, что твоих знаний не достаточно, а когда виден весь стек технологий, который нужно знать, то становится грустно. Даже если разобрался и сделал, то современем забудешь все.
На начальном этапе работы такое ощущение нормально, оно скоро пройдет. Если оно и через год никуда не делось, то дело пахнет керосином, лучше менять работу, эта не по зубам.
С вами бесполезно спорить на эту тему. Потому что вы сетевик. Циски и хуавей выучили и тыркаете их бесконечно. Я тоже в свое время хотел уйти в сети. Хорошая специализация. Никто не парит мозг по другим вопросам.
Никто не парит мозг по другим вопросам.
Вы серьезно?
ЛЮБАЯ проблема у коллег из других подразделений — и в мою сторону начинают коситься. Думаю, любой сетевик чувствует мою боль. Надо знать весьма много про как минимум то, как разные ОС и приложения ведут себя в сети. А нередко приходится со вздохом открывать логи и конфиг чужого сервиса и тыкать пальцем тыкать в проблему, потому что так быстрее отвяжутся.
А в последнее время я заметил, что приходится много скриптов писать, потому что иногда они эффективно решают имеющиеся проблемы. Скажем, есть у меня скрипт, который при повышении процента неудачных вызовов по SIP транку выгружает многомегабайтный дамп пакетов с трафиком сигнализации (без голоса) за несколько последних минут, выполняет анализ по полученным от оператора связи кодам завершения, делает вывод о наличии или отсутствии проблемы, и если проблема есть — шлет в почту общую статистику за 2 минуты и трейс одного из неудачных вызовов, который завершился лидирующим по числу упоминаний кодом. Пару дней писал, еще пару недель допиливал до нулевого числа ложных срабатываний. Ну а что, надо же иметь мониторинг. Система, генерирующая вызовы, непоказательна, для нее все аварии операторов связи остаются незамеченными, надо на периметре смотреть.
Что до «циски выучили» — нет, далеко не выучил. Я много лет каждый день продолжаю их учить, и процесс этот бесконечен. Всегда появляется новый функционал, новые фичи, новые железки со своими особенностями. Да и по старым железкам и фичам можно долго копать вглубь. Даже если сконцентрироваться на одном направлении (ни разу не мой случай), например — роутинге и свитчинге, там все равно матчасти на годы вперед наберется. И это здорово.
увеличивать штат и вводить специализации, если организация крупная. Если мелкая — стараться не разводить зоопарк технологий
Добро пожаловать в стан программистов!
Тоже в свое время перескочил из сетевых администраторов (работал в магистальном ISP) в программисты и нисколько не жалею. В админстве больше всего напрягало, что нужно держать в голове кучу знаний, из которых в текущей работе нужны, от силы, процентов пять. Но если вдруг случается коллапс, то надо в срочном порядке поднимать пласты из самых дальних закоулков памяти и применять их в условиях наличия орущего над ухом шефа. В общем, то еще развлечение :-)
Тоже в свое время перескочил из сетевых администраторов (работал в магистальном ISP) в программисты и нисколько не жалею. В админстве больше всего напрягало, что нужно держать в голове кучу знаний, из которых в текущей работе нужны, от силы, процентов пять. Но если вдруг случается коллапс, то надо в срочном порядке поднимать пласты из самых дальних закоулков памяти и применять их в условиях наличия орущего над ухом шефа. В общем, то еще развлечение :-)
ээх, а я наоборот получал от этого кайф, всегда удивительно как пригождались знания которые ты никогда не считал относящимся к своей работе. В случаях аварий я всегда в какой-то транс впадал, и руки на автомате набивали
sh ip ro
sh ip bgp su
sh ip ospf dat
когда ты знаешь, что от каждой минуты которую ты тратишь на дебаг, страдают тысячи клиентов, начинаешь мыслить как-то очень быстро и чисто. всегда любил такие моменты.
sh ip ro
sh ip bgp su
sh ip ospf dat
когда ты знаешь, что от каждой минуты которую ты тратишь на дебаг, страдают тысячи клиентов, начинаешь мыслить как-то очень быстро и чисто. всегда любил такие моменты.
Вокруг Python ходил очень долго, — тормозила его относительная молодость
Ну как сказать молодость: Python появился в 1991, а, например, Java только в 1995.
Больше к обсуждению напишу комментарий, чем к тексту:
Работа админа на треть организационная (работа с людьми, выстраивание организационных процессов), на треть архитектурная (техническое планирование) и только на треть собственно техническая (сервис там настроить, глюк починить, скрипт написать).
Если у вас было не так, значит вы что-то делали не так.
Работа админа на треть организационная (работа с людьми, выстраивание организационных процессов), на треть архитектурная (техническое планирование) и только на треть собственно техническая (сервис там настроить, глюк починить, скрипт написать).
Если у вас было не так, значит вы что-то делали не так.
А если каждой из трех частей занимается отдельное подразделение? Или первая часть на одном подразделении, вторая и третья в пропорции 1/4 (нет причин архитектуре занимать больше времени) на другом? Неужели надо, чтобы обязательно каждый из многих десятков администраторов совмещал все эти три направления?
В больших командах — возможно и не так как я написал. У нас было человек 6-7 по трем зданиям (и еще десятка полтора в других городах, но они во многом сами по себе варились) и для той команды это было скорее справедливо чем нет (но я тогда этого еще не понимал).
Последнее время приходится работать в небольших командах, для них это 100% справедливо.
Последнее время приходится работать в небольших командах, для них это 100% справедливо.
Абсолютно с вами согласен. Любая достаточно крупная организация, для которой проблемы в ИТ означают простой бизнеса, скорее рано, чем поздно, приходит к такой модели.
Еще Булгаков писал, что каждое ведомство должно заниматься своим делом. Специалист по инфраструктуре не должен заниматься организационными вопросами и работой с пользователями, а саппорт не должен заниматься серверами и сетью — именно по причине тех самых проблем, которые описал автор поста.
Разумеется, все это справедливо для крупных компаний с сопоставимым штатом и структурой ИТ.
Разумеется, все это справедливо для крупных компаний с сопоставимым штатом и структурой ИТ.
Поддерживаю, хорошо сказал.
ТС, не попробовали стать системным инженером? Это, имхо, намного интереснее.
Вы допустили распространенную ошибку, путая две разные профессии: «Дело в самой профессии системного администратора. Работа, конечный итог которой стремится к абсолютной ле́ни, сильно расслабляет жизненные позиции и стремления, а общение с пользователями и выслушивание их недовольств, еще больше укрепляет асоциальные начала».
Из одной этой фразы можно сделать вывод, что вы были не админом, а шивой. Лично я в таком качестве выдержал чуть более, чем полгода, после чего ушел в инфраструктурные админы, где могу спокойно заниматься своим делом, не отвлекаясь на посторонние раздражители, а для «выслушивания недовольств пользователей» есть отдел техподдержки.
Из одной этой фразы можно сделать вывод, что вы были не админом, а шивой. Лично я в таком качестве выдержал чуть более, чем полгода, после чего ушел в инфраструктурные админы, где могу спокойно заниматься своим делом, не отвлекаясь на посторонние раздражители, а для «выслушивания недовольств пользователей» есть отдел техподдержки.
Вы где-то не там админом работали. А 40 серверов — это один маленький кластер для небольшого инфраструктурного сервиса.
Много чем приходится заниматься в администрировании и всегда что то новое, то задачи подкинут то сам чего вычитаешь. Единственное огорчает это что не все технологии сможешь постичь.
Тоже думал уйти в программисты так как один момент была лютая рутина, но посмотрев на зарплаты и пообщавшись с друзьями программистами, послал эти мысли по дальше. В администрировании и программирование и работа с людьми и управление есть, много направлений куда расти. Так что продолжаем админить.
Тоже думал уйти в программисты так как один момент была лютая рутина, но посмотрев на зарплаты и пообщавшись с друзьями программистами, послал эти мысли по дальше. В администрировании и программирование и работа с людьми и управление есть, много направлений куда расти. Так что продолжаем админить.
>сам процесс поддержки, а точнее его «постоянная» природа или отсутствие какой-либо завершенности. Мелкие задачи, выполняясь, накладываются друг на друга до бесконечности и превращаются в огромный ком
За что мне нравилась работа сисадмина так это за ее конечность — после построения отказоустойчивой системы и автоматизации всего и вся можно сидеть и спокойно заниматься своими делами, получая зарплату.
Если бы еще в офис ходить не надо было — вообще идеал.
Ну то есть если вас кто-то дергает — либо это косяк в системе, которую вы построили — ломается она, либо это эникейство — когда юзеры бесконечно прут. Переезжайте в столицу, велком в DevOps. Тем паче питон знаете, ansible в руки :)
>В-вторых, прерывания. В деле системного администрирования они особо выделяются из всех проблем и могут вывести из душевного равновесия любого.
>У хороших системных администраторов свободного времени намного больше, чем они говорят. Благодаря чему копится много подписок, каналов на ютубе, профильные сайты, шутки-прибаутки, много знакомых в сети и интересов. Лично у меня могло до трех часов в день уходить на чтение и просмотр всего этого.
Мне кажется, автор не совсем понял, чего ему действительно хочется — похоже, чтобы не отвлекали от просмотра ютуба.
Ну, у программистов с этим намного напряжнее.
У кодеров же работы всегда невпроворот — сколько не программируй, начальство новых проектов накидает в любой момент выше крыши.
Ну и да, квалифицированные админы — исчезающий вид.
В будущем останутся только эникейщики, принтеры заправлять и мышки менять, и DevOps — по сути программисты, полностью автоматизирующие админскую рутину.
За что мне нравилась работа сисадмина так это за ее конечность — после построения отказоустойчивой системы и автоматизации всего и вся можно сидеть и спокойно заниматься своими делами, получая зарплату.
Если бы еще в офис ходить не надо было — вообще идеал.
Ну то есть если вас кто-то дергает — либо это косяк в системе, которую вы построили — ломается она, либо это эникейство — когда юзеры бесконечно прут. Переезжайте в столицу, велком в DevOps. Тем паче питон знаете, ansible в руки :)
>В-вторых, прерывания. В деле системного администрирования они особо выделяются из всех проблем и могут вывести из душевного равновесия любого.
>У хороших системных администраторов свободного времени намного больше, чем они говорят. Благодаря чему копится много подписок, каналов на ютубе, профильные сайты, шутки-прибаутки, много знакомых в сети и интересов. Лично у меня могло до трех часов в день уходить на чтение и просмотр всего этого.
Мне кажется, автор не совсем понял, чего ему действительно хочется — похоже, чтобы не отвлекали от просмотра ютуба.
Ну, у программистов с этим намного напряжнее.
У кодеров же работы всегда невпроворот — сколько не программируй, начальство новых проектов накидает в любой момент выше крыши.
Ну и да, квалифицированные админы — исчезающий вид.
В будущем останутся только эникейщики, принтеры заправлять и мышки менять, и DevOps — по сути программисты, полностью автоматизирующие админскую рутину.
В нашей стране есть одна особенность на рынке IT труда. И у сисадминов, и у программистов очень высокий разброс зарплат. Низкий старт, но высокий потолок. Если начинающий айтишник может начинать с 15-20, то по мере повышения ценности для бизнеса его цена будет расти до 150-200. Нужно понять, что платят не за знания, а за пользу которую человек представляет конкретному бизнесу. Если айтишник это обслуга, то и зп будет соответсвующей, если ключевая часть инфраструктуры, то разительно другая, вне зависимости от реальной сложности работы. Так же наш рынок труда отличается высокой неравномерностью. Это отражает структуру экономики, где существует денежный голод в среднем и малом бизнесе, и переизбыток денек в крупном бизнесе. Поэтому в среднем и малом бизнесе кадровый голод и нехватка специалистов, а в крупном бизнесе в среднем по три человека на вакансию… а может и больше.
Какой выход? А никакого. Либо специализируйтесь и вставайте в очереди на вкусные вакансии, либо ищите компанию, которая захочет вас растить как специалиста под себя и держитесь за нее пока не окрепнете профессионально. Второй вариант для тех кому за 30 будет практически закрыт. И повторюсь это в одинаковой степени касается и сисадминов, и программистов. Бизнесу нужны люди, которые ушли в глубь, а на людей с широким кругозором, которых активно и часто успешно готовит наше образование, им наплевать. Точнее такие люди тоже нужны, но они быстро уходят в менеджеры, а так как их нужно существенно меньше, то уже действующим менеджерам конкуренты не нужны, и если у вас действительно широкий кругозор, то это станет скорее вашим минусом, чем плюсом.
Какой выход? А никакого. Либо специализируйтесь и вставайте в очереди на вкусные вакансии, либо ищите компанию, которая захочет вас растить как специалиста под себя и держитесь за нее пока не окрепнете профессионально. Второй вариант для тех кому за 30 будет практически закрыт. И повторюсь это в одинаковой степени касается и сисадминов, и программистов. Бизнесу нужны люди, которые ушли в глубь, а на людей с широким кругозором, которых активно и часто успешно готовит наше образование, им наплевать. Точнее такие люди тоже нужны, но они быстро уходят в менеджеры, а так как их нужно существенно меньше, то уже действующим менеджерам конкуренты не нужны, и если у вас действительно широкий кругозор, то это станет скорее вашим минусом, чем плюсом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От linux-админа к python-программисту или как и почему я менял профессию