Да можно сколько угодно вокруг этих мыслей ходить, но я бы сформулировал так:
Диплом нужен, но:
Релевантный специальности.
Из правильного ВУЗа (топ 5-10 в РФ).
Очный.
Не купленный.
В остальном подобного рода дискуссии просто ходят вокруг этих фактов и обобщая никак не могут договориться :)
p.s. Бросил универ на 5ом курсе, он совершенно не имел отношения к IT и получи я там диплом - в моей карьере бы вот совсем ничего не изменилось. При этом вполне верю что имея диплом, например, МФТИ все могло бы быть совсем по другому.
А с другой стороны зачем нужен хороший средний программист? Виртуозно клепать формочки, отчеты и ковыряться в легаси на зарплате? Объективно разработка для многих стала ремеслом а не творчеством и глобально что-то привнести в сферу уже очень мало кому удается. Исключения лишь подтверждают правило, но и их становится все меньше с ростом сложности технологий и доминирования корпораций в IT. И да, я думаю это нормально.
Я не про перс. данные. Я про фин. документы, например
Ну фин. документы, какие-то инсайды и прочее такое тоже могут повлиять как минимум на репутацию компании и финансовые показатели, как максимум на целые рынки. Тут просто надо смотреть глобальнее и тогда такие меры начинают казаться оправданными.
ИБ компании просто нужно было, чтобы была физическая передача. Чтоб акт составить. Вот ценный диск. Вот мы его передали. Дальше не наша ответственность. А интернет -черный ящик.
Ну это достаточно обоснованное мнение и как бы не хотел я во многом с ним согласен.
Сложно сказать, архив запоролен. Попадет не в те руки.. Типа шел, шел, потерял флешку. Ну такое конечно мей би, но вероятность низкая. Ну и нашедший флешку с запороленным архивом будет довольно долго его взламывать (если вообще будет)
К чему приводили забытые(?) в баре прототипы айфонов или какие-нибудь важные ноутбуки интернет помнит)
Ну да, оно в теории верно, что сначала надо согласовать. Согласовывать будете недели 2, а работать надо "вчера". Какой-нить Сбер может себе позволить простой работника в месяц. А другие организации - не очень
А чтобы было не 2 недели - нужны процессы способные ускорить и облегчить эту процедуру. Как раз сбер со своими ~300к сотрудников я думаю в этом на внутренней кухне достаточно приуспел, иначе бы оно вообще не смогло шевелиться.
Оно нельзя, когда для плохих целей. Вон тот Денисович попался не потому, что базу слил, а потому что использовал ее в плохих целях. А если бы он эту базу использовал для хороших целей (губеру бы отнес, хз зачем, ситуация выдуманная), то никаких проблем бы у него не было. Еще бы и премию получил
Есть данные которые нельзя предоставлять третьим лицам, совсем. И персоданные тут на первом месте (вспомните как в один момент все начали подкидываться с GDPR).
CD-r. А откуда у Вас на компе есть CD-r и будет ли читалка на той стороне? да и чем это безопасней то? Денисочу было бы гораздо проще, будь у него писалка дисков. А так пришлось с почтой извращаться
а) Иммутабельность б) После отчуждения ответственностьза сохранность фактически на конкретном лице (я б на его месте мухлевать не стал).
Таковы были условия передачи с принимающей стороны согласованные с ИБ компании в которой я на тот момент работал. Ивану Денисовичу было бы +- одинаково)
У коллег есть право. Но доступа нет. например это холдинг. Вы работаете в УК. Формально у Вас есть право смотреть их доки (ну, финотчеты например). Но нет доступа в их компы. Опять таки в целях безопасности. Вам могут только передать эту инфу (таким образом передающий сотрудник несет ответственность за передачу)
Ну так вот надо сначала согласовать подход к передаче данных и как гарантировать их безопасноть, а не прыгать с завязанными глазами по граблям. Давайте перефразирую, если в ходе вашего придуманного на коленке процесса передачи часть чувствительных данных попадут не в те руки, при этом кто передавал понятно и последствия для вас не радужные (менее чем у Ивана Денисовича, но все таки) - что делать и кому плакаться?
Вы рассуждаете с точки зрения идельного мира. А фактические ситуации они шире. А на каждый чих прописывать правила в айти-системе и в инструкциях - невозможно
Я рассуждаю с точки зрения процессов которые в том или ном виде работают последние несколько десятков лет в финтехе, поскольку и статья про финтех. Как передавать сверхсекретный шаблон сайта на ucoz'e для команды в контре - да как удобнее в принципе)
В бытность моей работы, я скидывал архив одного проекта на свой личный яндекс-диск. С точки зрения СБ - утечка. А с точки зрения нач. отдела - бекапы в разных местах
Ну тут без комментариев, в больших компаниях бэкапить что-то сколь либо чувствительное "во вне" нельзя, совсем.
Каким образом предлагаете передавать даннные (в которые запрещено сувать нос сотрудникам, за пределами узкого круга. В том чисел СБ-истом тоже нельзя) кроме как архивом? Экселевские запороленные файлы взламываются проще, насколько я знаю
Вариантов больше чем кажется. Мне вот приходилось записывать cd-r и передавать под роспись результаты работы одной запатентовоной деньгоприносящей штуки (понятно что и там все запаролено, пароль передавался отдельно).
При этом эти данные бывает надо передать своим же коллегам. Или не своим, а каким-то консалтерам
У коллег либо есть легитимный доступ к данным, либо нет. Третьего не дано.
p.s. Если что я не ИБшник, но наверное слишком давно в финтехе.
Это факт, но в целом аномалии со временем искать получается неплохо.
Ну и еще - безопасники мешают работать людям
Ну во первых это финтех и аудиторы с PCIDSS не дремлют. Во вторых - с позиций удобства согласен, с позиции бизнеса - это необходимое зло (или не зло).
Допустим, Вы запретили записывать запороленные архивы на флешки. А если сотруднику надо (именно надо) передать кому-то запороленный архив. И не дело безопасников сувать туда нос (поэтому и заполоролен, в целях безопасности)
Обычно есть регламентированные пути передачи чувствительных данных, не архивчики. Но да, ситуаций где кому-то будет неудобно из-за очередной инновационной DLP можно придумать (и не придумать) массу.
Бэкапы обычно отчуждаемы, за базой тоже весьма серьезный контроль (в том числе регламентированный PCIDSS). Вот если есть доступ к ETL в проме и подобная активность легетимна, а в трансформациях особенно никто не разбирается - вот там уже и контент фильтр обойти кажется что не такая уж проблема.
Ниже прокомментировал. Если говорить о Learn Python, то уж чего мы никогда не делаем, так это не обещаем быстрого и лёгкого входа в айти. На стриме (опять же ссылка ниже), кстати, я об этом тоже говорю.
Ниже уже писал что зря не отразили и сложности через которые прошел Сергей. Было бы намного интереснее и не создавалось впечатления какой-то сильно обрезанной сказки о красивой жизни. Причем даже "мотивирующая" часть где-то потерялась.
Но наверное, за несколько лет курсов могла и у нас быть некоторая удача. И конечно, мы ни в коем разе не говорим о том, что это типовой случай.
Вопросы были к материалу, а не к вам или компании.
Окей, всё описанное приправьте мысленно фразой "А ещё он всё это время пахал" и получится желаемый результат - так должен был выглядеть "полноценный материал"?
Зависит от таланта автора.
Рекламная брошюрка чего, извините, получилась? Устройства в Теслу и того, что всё в силах самого человека? :)
Мы в корпоративном блоге это раз, в начале статьи:
Компания Geekfactor cовместно с Getmentor.dev проводит программу подготовки к трудоустройству в зарубежные стартапы (бесплатно помогаем подготовиться к интервью и показываем резюме классным компаниям) — почитать о ней подробней и зарегистрироваться можно тут.
Это два
Но это не совсем наша заслуга — Сергей просто классный и много вкалывал, да и не с нашей программой учился, а на дружественных курсах Learn Python.
Ну и конечно случайно нашедшиеся дружеские курсы три.
Ну не чудо ли брошюрка? =)
p.s. Вот теперь и я вас прорекламил, это кажется заразно.
Вопросы возникают с 7 лет госслужбы этому предшествовавших и финансовой подушки позволившей год дрочить LeetCode в Америке и сколько-то до этого в России.
Я не считаю чужие деньги, но статья и правда вызывает много вопросов и похожа на очередную красивую иллюстрацию "войтивайти" для очередного скиллбокса.
Проблема знакомая и мне кажется состоит из двух частей:
Для generic HR - довольно существенное пересечение кейвордов, и не важно что при таком подходе senior admin окажется при таком подходе junior devops'ом (и наоборот).
Девопсы бывают разные, но использование облаков в построении инфраструктуры во многом снижает требования к фундаментальным знаниям (там нужнее условные курсы AWS чем Таненбаум). Вот собственно поэтому и снижается роль "эксплуатации" в процессах и знания у людей несколько специфичны и вообще из другой оперы.
p.s. Я то вообще хадупсы с etl'ями кручу по финтехам, и то постоянно пытаются вакансии девопсов подсунуть и искренне удивляются когда отвечаю им что это не совсем мой профиль)
Это как дзен, но еще хуже?
Вот стоило переименоваться, а уже утерли яндексу нос!
То он найдет работу в другой компании. Может даже так для всех будет лучше.
Статья конечно полезная, но что-то мне подсказывает что 9 случаев проблем с памятью из 10 в python связаны с pandas :)
Вообще таких примеров что-то в районе статистической погрешности относительно всего числа it специлистов)
Да можно сколько угодно вокруг этих мыслей ходить, но я бы сформулировал так:
Диплом нужен, но:
Релевантный специальности.
Из правильного ВУЗа (топ 5-10 в РФ).
Очный.
Не купленный.
В остальном подобного рода дискуссии просто ходят вокруг этих фактов и обобщая никак не могут договориться :)
p.s. Бросил универ на 5ом курсе, он совершенно не имел отношения к IT и получи я там диплом - в моей карьере бы вот совсем ничего не изменилось. При этом вполне верю что имея диплом, например, МФТИ все могло бы быть совсем по другому.
Угумс, пост от pvs на хабре.
А с другой стороны зачем нужен хороший средний программист? Виртуозно клепать формочки, отчеты и ковыряться в легаси на зарплате? Объективно разработка для многих стала ремеслом а не творчеством и глобально что-то привнести в сферу уже очень мало кому удается. Исключения лишь подтверждают правило, но и их становится все меньше с ростом сложности технологий и доминирования корпораций в IT. И да, я думаю это нормально.
Ну фин. документы, какие-то инсайды и прочее такое тоже могут повлиять как минимум на репутацию компании и финансовые показатели, как максимум на целые рынки. Тут просто надо смотреть глобальнее и тогда такие меры начинают казаться оправданными.
Ну это достаточно обоснованное мнение и как бы не хотел я во многом с ним согласен.
К чему приводили забытые(?) в баре прототипы айфонов или какие-нибудь важные ноутбуки интернет помнит)
А чтобы было не 2 недели - нужны процессы способные ускорить и облегчить эту процедуру. Как раз сбер со своими ~300к сотрудников я думаю в этом на внутренней кухне достаточно приуспел, иначе бы оно вообще не смогло шевелиться.
Есть данные которые нельзя предоставлять третьим лицам, совсем. И персоданные тут на первом месте (вспомните как в один момент все начали подкидываться с GDPR).
а) Иммутабельность б) После отчуждения ответственностьза сохранность фактически на конкретном лице (я б на его месте мухлевать не стал).
Таковы были условия передачи с принимающей стороны согласованные с ИБ компании в которой я на тот момент работал. Ивану Денисовичу было бы +- одинаково)
Ну так вот надо сначала согласовать подход к передаче данных и как гарантировать их безопасноть, а не прыгать с завязанными глазами по граблям. Давайте перефразирую, если в ходе вашего придуманного на коленке процесса передачи часть чувствительных данных попадут не в те руки, при этом кто передавал понятно и последствия для вас не радужные (менее чем у Ивана Денисовича, но все таки) - что делать и кому плакаться?
Я рассуждаю с точки зрения процессов которые в том или ном виде работают последние несколько десятков лет в финтехе, поскольку и статья про финтех. Как передавать сверхсекретный шаблон сайта на ucoz'e для команды в контре - да как удобнее в принципе)
Ну тут без комментариев, в больших компаниях бэкапить что-то сколь либо чувствительное "во вне" нельзя, совсем.
Вариантов больше чем кажется. Мне вот приходилось записывать cd-r и передавать под роспись результаты работы одной запатентовоной деньгоприносящей штуки (понятно что и там все запаролено, пароль передавался отдельно).
У коллег либо есть легитимный доступ к данным, либо нет. Третьего не дано.
p.s. Если что я не ИБшник, но наверное слишком давно в финтехе.
Это факт, но в целом аномалии со временем искать получается неплохо.
Ну во первых это финтех и аудиторы с PCIDSS не дремлют. Во вторых - с позиций удобства согласен, с позиции бизнеса - это необходимое зло (или не зло).
Обычно есть регламентированные пути передачи чувствительных данных, не архивчики. Но да, ситуаций где кому-то будет неудобно из-за очередной инновационной DLP можно придумать (и не придумать) массу.
Бэкапы обычно отчуждаемы, за базой тоже весьма серьезный контроль (в том числе регламентированный PCIDSS). Вот если есть доступ к ETL в проме и подобная активность легетимна, а в трансформациях особенно никто не разбирается - вот там уже и контент фильтр обойти кажется что не такая уж проблема.
И я там был (с) Команда и правда классная, да и штат относительно среднего банка микроскопический.
p.s. Месье выше скорее подразумевал тех. команду в виде технологов/аналитиков итд. IT там вполне себе актуального поколения))
Так и СБП сильно изменила ситуацию с переводами на внутреннем рынке. ЕМНИП почти монополист с весьма серьезными комиссиями был сбер до того момента.
Ниже уже писал что зря не отразили и сложности через которые прошел Сергей. Было бы намного интереснее и не создавалось впечатления какой-то сильно обрезанной сказки о красивой жизни. Причем даже "мотивирующая" часть где-то потерялась.
Вопросы были к материалу, а не к вам или компании.
Зависит от таланта автора.
Мы в корпоративном блоге это раз, в начале статьи:
Это два
Ну и конечно случайно нашедшиеся дружеские курсы три.
Ну не чудо ли брошюрка? =)
p.s. Вот теперь и я вас прорекламил, это кажется заразно.
Ну и зря, получилась рекламная брошюрка с приглашенным "достигшим" в худших традициях какой-нибудь БМ вместо полноценного материала.
Вопросы возникают с 7 лет госслужбы этому предшествовавших и финансовой подушки позволившей год дрочить LeetCode в Америке и сколько-то до этого в России.
Я не считаю чужие деньги, но статья и правда вызывает много вопросов и похожа на очередную красивую иллюстрацию "войтивайти" для очередного скиллбокса.
Проблема знакомая и мне кажется состоит из двух частей:
Для generic HR - довольно существенное пересечение кейвордов, и не важно что при таком подходе senior admin окажется при таком подходе junior devops'ом (и наоборот).
Девопсы бывают разные, но использование облаков в построении инфраструктуры во многом снижает требования к фундаментальным знаниям (там нужнее условные курсы AWS чем Таненбаум). Вот собственно поэтому и снижается роль "эксплуатации" в процессах и знания у людей несколько специфичны и вообще из другой оперы.
p.s. Я то вообще хадупсы с etl'ями кручу по финтехам, и то постоянно пытаются вакансии девопсов подсунуть и искренне удивляются когда отвечаю им что это не совсем мой профиль)
Интересно, но по сути описан тот самый "hype cycle" от Gartner и сейчас openstack вполне идет к описанному там "плато".