Всегда говори да!

«Обычно люди обращаются за советом, — говорил Атос, – только для того, чтобы не следовать ему, а если кто-нибудь и следует совету, то только для того, чтобы было кого упрекнуть впоследствии.»

Пришло мне в голову дать вам бесплатный совет: соглашайтесь на практически любую движуху. Приведу пару примеров из своего опыта:

  1. 2009-й год, я работаю обычным системным администратором на заводе. Windows, Exchange и немножко ДрВеба с Симантеком :).
    Тут мне предлагают стать ответственным за администрирование коммутаторов, маршрутизаторов и брандмауэров Cisco. В качестве бонуса еще и немного учат!
    Я, конечно же, соглашаюсь. Коллега из соседнего отдела сомневается и отказывается – зачем ему дополнительный головняк?
  2. 2011 год, в другом месте мне предлагают взяться за администрирование системы MS Lync Server 2010. Тоже учат, ага…
    Там же ближе к 2017 – внедрить систему резервного копирования NetBackup.

Результатом первой возможности стало более глубокое понимание работы сети и сертификат CCNA (хотя, поработав в интернет-провайдере, я осознал – насколько же это были базовые знания). Пару раз помогало тыкать носом сетевиков в их косяки.
Результатом второй и третьей – приличные знания по обеим системам в качестве T-shape специалиста. В результате, в 2020м меня брали на центрального администратора Commvault с хорошим окладом без практического опыта по нему 😉

Я не могу рассказать о текущем стеке, но он не имеет ничего общего с привычным мне VMware/Microsoft. Когда-нибудь я расскажу и эту историю…

12 thoughts on “Всегда говори да!”

  1. Это что-то из корпоративного мира с жестким разделением обязанностей?
    У меня в интеграторе всегда была возможность заняться чем-то ещё, но в какой-то момент пришло понимание, что уровня шивы недостаточно для качественного выполнения своей работы и лучше сосредоточиться на чём-то одном и смежные области доверить профессионалам в них.

  2. Я согласен с тем, что времени не хватит поддерживать на экспертном уровне “уровень шивы” в различных областях (например, MS+Cisco+VMware из примера выше). Уровень эксперта – это CCIE (), VCDX и что-нибудь наподобие у MS. Уровень попроще – в принципе, достижим (ну и я бы поспорил, что из меня был плохой vSphere’щик или Skype for Business’щик )))
    Проблема с “сосредоточиться на чем-то одном” вот в чем:
    1) вы можете переоценить свою экспертность в данной области. И когда потребуется поискать новую работу – окажетесь неприятно удивлены;
    2) в случае “схлапывания” рынка вам придется почти с нуля и без опыта изучать новую сферу;
    3) большинство областей все же достаточно ограничены. Например, я не понимаю “чего” изучать в MS Exchange или VMware vSphere 10 лет (помимо следования версиям).

    Многорукой шиве все же проще…

  3. Я имел в виду связанные направления, тот же EXS + SPS + Lync + интеграции не хватит одной головы изучить на уровне эксперта даже за 10 лет, а уж премьер поддержки постоянно будешь узнавать что-то новое. А vSphere легко вырастает в VCF, где куча сложных и непохожих друг на друга продуктов.

    Про экспертность тоже спорно, тот же CCNP в провайдерской сети трудно совмещать с чем-то ещё на схожем уровне (один раз получить сертификат не в счёт), а VCDX больше про дизайн, чем про экспертизу по продуктам.

  4. Или давай реальный пример, после увольнения второго админа я взялся админить Gitlab, научился его настраивать через гуй, конфиги и rails-console, закрыл несколько висяков и исправил пару багов, вроде всё классно?

    Было, пока не пришлось откатывать сервер к бекапу и повторно накатывать изменения в репозитории с компов программистов, чтобы не потерять рабочий день. Тут выяснилось, что мои “знания” ничего не стоят и нужен настоящий админ знающий git. При этом ты сам и руководство легко может подумать, что на самом деле направление закрыто и никого нанимать не нужено (пока не наступит день П).

  5. T-Shape специалист, это же не про “далее-далее-готово”, а про полноценное обслуживание указанной системы. Емнип, когда я отвечал за skype+netbackup, я выдавал десятки страниц инструкций на разные случаи жизни (в том числе и для восстановления этих систем) 🙂
    Другой вопрос, что документацию по Netbackup’у никто не прочел, вследствие чего коллегам понадобилась моя помощь через неделю после увольнения…
    P.S. Ну и рабочий пример: прокачавшись в навыке установки и обслуживания Gitlab onPremise, вы сможете развернуть и обслуживать систему, содержащую десяток серверов в отказоустойчивом исполнении. Это немного отличается от вашей постановки задачи, не так ли?

  6. T-shaped специалист как раз про это, когда хорошо знаешь своё направление и пишешь десятки страниц инспекций и ещё немного смотрел остальные. Бахнуть в Oracle запрос на утилизацию таблиц, подкрутить параметры JVM в WAS или исправить пайплайн в Jenkins, но не локализовать в них баг или проблему производительности.

    А Gitlab ставится одним пакетом и совсем не вдохновляет на автоматизацию пока ты не пользуешься его CI.

    1. Как мне кажется, T-Shape – как раз про “локализовать баг или проблему производительности” в Jenkins или Oracle, используя смежные представления об архитектуре ОС и/или виртуализации, специфику тюнинга Java и представления о работе СУБД.
      Держать отдельного человека под Oracle (или вообще под СУБД) еще имеет смысл.
      Но под Jenkins или Gitlab? Они что делать-то будут 90% своего времени? 🙂

      Собственно, мой совет и был про это: если вы видите (или вам предлагают) рядом обязанности, которые повышают вашу эффективность больше, чем дальнейшая прокачка вашего ключевого скилла, то надо сходить и согласиться.
      Просить за это деньги авансом – можно, но лучше же просить их с обоснованием 😉

      1. Просто Gitlab и Jenkins должен сопровождать девопс админ девелоперской инфраструктуры, который ещё крутит Artifactory, Jira и всякие линуксы. С адинистрирование инфраструктуры (VMware, Microsoft) это плохо сочетается.

        1. Мне кажется, что зацикливание слова “инфраструктура” исключительно на VMware+Microsoft даже в 2021 уже было моветоном.
          Равно как и нежелание вышеуказанного специалиста копать в сторону Linux %-)

          1. У меня есть RHCE по Ансиблу, но это самый базовый уровень с которым нельзя пускать в продакшен.
            А Microsoft с VMware до сих пор лидеры рынка и лучше них на опенсорсе вряд ли получится сделать.

  7. Еще я забыл указать дисклеймер: надо всегда помнить про ошибку выжившего. Даже буквальное повторение моих (либо чьих-то других) шагов отнюдь не гарантирует какого-либо успеха.
    Согласие выполнять дополнительные и бесполезные обязанности (например, подработка дворником) – тоже.
    Согласие что-то делать в ущерб основной деятельности/скиллу – тоже.
    Селяви.

    1. Не обязательно бесполезные и непрофильные, а просто бесперспективные. Например, учиться сопровождению AS/400, что может быть очень интересно и сэкономить немного денег текущему работодателю, но польза для резюме от неё никакой.

      Ещё отзывчивым любят садиться на шею и тут тоже надо быть на чеку.

Leave a Reply

Your email address will not be published. Required fields are marked *